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)
Tracking
()
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.
Assignee | ||
Comment 1•4 years ago
|
||
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]
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
With Adam's help I think I got to the bottom of this. My explanation is in the commit message, hopefully it's clear.
Comment 4•4 years ago
|
||
bugherder |
Description
•