Closed Bug 1687777 Opened 4 months ago Closed 2 months ago

Schedule background update backgroundtask

Categories

(Toolkit :: Application Update, task)

task

Tracking

()

RESOLVED FIXED
89 Branch
Tracking Status
firefox89 --- fixed

People

(Reporter: nalexander, Assigned: nalexander)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file, 1 obsolete file)

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.

Duplicate of this bug: 1458283

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

Assignee: nobody → nalexander
Status: NEW → ASSIGNED

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

Depends on: 1694515

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.

Attachment #9202249 - Attachment is obsolete: true

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 to about: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.

Pushed by nalexander@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/01887a1c8c75
Schedule OS-level `--backgroundtask backgroundupdate` on Windows. r=mossop,bytesized,flod
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch
Regressions: 1701502
Blocks: 1703302
Depends on: 1705281
Blocks: 1705281
No longer depends on: 1705281
You need to log in before you can comment on or make changes to this bug.