This ticket incorporates Bug 1568287, most likely, since we'll need to land on some schedule for running the background update task. either does not have in default profile, or has no langpacks in default profile.has an omnijar (there's no sense trying to update developer builds).does not have in default profile (on Windows, this is any profile).has an pref flipped on (or is otherwise opted in).From my notes, the criteria should include: Thus, this ticket also incorporates determining the first version of eligibility for background updates. In particular, I expect to schedule the update tasks from within Firefox itself, and only when the default browsing profile is in use, so that we have the "correct" set of prefs and extensions (langpacks) to determine eligibility. The move was not liked by all users of the browser. When Mozilla announced the rapid release cycle for Firefox, it did so to get features and updates to users faster and to stay competitive.
I'm not a proponent of superceding old tickets in general, but the latter has a lot of discussion of using PostUpdateTask that isn't the technical approach I intend to pursue with the new background task machinery. Mozilla announced a change to the release schedule of the Firefox web browser that moves it from a six-week interval to a variable interval. This ticket tracks making Firefox schedule the background task that actually downloads and stages updates, using the in-Gecko background task machinery of Bug 1667276 for actually doing the update logic and the task scheduler machinery of Bug 1676296 for scheduling (at least, on Windows).
0 kommentar(er)
