Closed Bug 1700987 Opened 4 years ago Closed 4 years ago

Ensure that `update.status` error 105 (won't prompt for UAC in background mode) is handled correctly in `--backgroundtask backgroundupdate`

Categories

(Toolkit :: Application Update, task)

task

Tracking

()

RESOLVED FIXED
89 Branch
Tracking Status
firefox89 --- fixed

People

(Reporter: nalexander, Assigned: nalexander)

References

Details

Attachments

(1 file)

In my local testing of the --backgroundtask backgroundupdate stack, there's an interaction between the work in progress and Bug 1696276 that I haven't yet tracked down. This ticket is a placeholder for that investigation.

When app.update.staging.enabled=true (in the default profile) and elevation is required (say, because the installation is rooted in c:\Program Files), --backgroundtask backgroundupdate produces update.status 105 (won't prompt for UAC in background mode). That's expected after Bug 1696276.

But a subsequent --backgroundtask backgroundupdate doesn't update the 105 back to pending, and I haven't quite worked out why. It rather looks like the command line handling isn't quite working and there's a (partially?) headed browser being launched. Or it might be that the update driver isn't correctly invoking the code that would handle this case.

This wasn't being invoked for a number of reasons. First, the
profile-after-change category notification is not registered in
background task mode. But we don't want to register it for all
background tasks, thereby loading the update service in all tasks. So
we manually prod the relevant code. We do this via the
UpdateServiceStub constructor, instead of more directly, so that there
is a single entry point to this functionality in and out of background
task mode. However, this requires not delaying post update processing
in background task mode.

The change to use the best pending state allows the backgroundtask to
try to use the Maintenance Service multiple times.

With this change, repeated --backgroundtask backgroundupdate
invocations with:

a) staging enabled
b) the Maintenance Service available
c) a MAR that the Maintenance Service will not accept

Leads to a loop like:

$ --backgroundtask backgroundupdate
  update.status="pending"
$ --backgroundtask backgroundupdate
  after updater.exe
    update.status="failed: 105"
  update.status="pending-service"
$ --backgroundtask backgroundupdate
  after MMS
    "failed: 49"
  update.status="pending"
$ --backgroundtask backgroundupdate
  after updater.exe
    update.status="failed: 105"
  update.status="pending-service"
[repeated]
Assignee: nobody → nalexander
Status: NEW → ASSIGNED

With Adam's help I think I got to the bottom of this. My explanation is in the commit message, hopefully it's clear.

Pushed by nalexander@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ca3865021307 Invoke `post-update-processing` in `--backgroundtask backgroundupdate`. r=application-update-reviewers,bytesized
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: