Schedule background update backgroundtask
Categories
(Toolkit :: Application Update, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox89 | --- | fixed |
People
(Reporter: nalexander, Assigned: nalexander)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file, 1 obsolete file)
Bug 1687777 - Schedule OS-level `--backgroundtask backgroundupdate` on Windows. r?Mossop!,bytesized!
(deleted),
text/x-phabricator-request
|
Details |
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).
This obsoletes, I think, Bug 1458283. 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. 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. Thus, this ticket also incorporates determining the first version of eligibility for background updates. From my notes, the criteria should include:
- has an
app.update.background
pref flipped on (or is otherwise opted in) - does not have
app.update.auto
in default profile (on Windows, this is any profile) - has an install (on Windows)
- has an omnijar (there's no sense trying to update developer builds)
- either does not have
app.update.langpack.enabled
in default profile, or has no langpacks in default profile
This ticket incorporates Bug 1568287, most likely, since we'll need to land on some schedule for running the background update task.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
My immediate use case is making the name for a Windows Scheduled Tasks
agree with the existing task names for the Windows Default Browser
Agent task name. The latter uses MOZ_APP_DISPLAYNAME
in its static
metadata and from C++.
We want to strongly discourage users from using MOZ_APP_DISPLAYNAME
in dynamic contexts, hence the long comment; but it's not worth
establishing a lint limiting uses at this time.
Depends on D104638
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
This ticket checks whether it's appropriate to schedule updates in the
background, i.e., when the browser is not running, and then uses the
new OS-level Task Scheduler API to schedule said tasks.
Depends on D104639
Comment 4•4 years ago
|
||
Comment on attachment 9202249 [details]
Bug 1687777 - Pre: Expose MOZ_APP_DISPLAYNAME
in AppConstants. r?#build
Revision D104639 was moved to bug 1689519. Setting attachment 9202249 [details] to obsolete.
Assignee | ||
Comment 5•4 years ago
|
||
To verify that this is disabled by default, I fetched a recent try build, installed it (on Windows 10), and used about:config
to set:
app.update.background.loglevel
= "debug"app.update.background.experimental
= true
Then I went toabout:preferences
and confirmed that "When Nightly is not running" was unchecked. That's the switch in the off position.
Then I restarted the browser and observed the logging in the Browser Console saying background updates weren't scheduled due to app.update.background.enabled=false
, as expected.
Comment 7•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Description
•