529746 - [Win] App update should request elevation when the user doesn't have privileges to update

Status: NEW

(Toolkit :: Application Update, defect, P3)

Description

[Robert Strong (they/them - no direct email)]

spinoff for the Windows work for bug 318855. The majority of this work was already done in bug 437349

Comment 1

[Robert Strong (they/them - no direct email)]

beltzner / faaborg: can I get your thoughts on how I see the process flow below?

Elevation success process flow:
1. User downloads update and restarts Firefox
2. User is prompted for and enters credentials that have privileges to update
3. Update installs and Firefox restarts

Elevation failure process flow:
1. User downloads update and restarts Firefox
2. User is prompted for and enters credentials that don't have privileges to update
3. The updater binary sets an error code for this case and Firefox restarts
4. Error code is read by application update on startup
5. User is notified that the update could not be installed
   the notification provides the option to disable attempts to apply updates
   the user will continue to be notified of updates and given the option to download / install manually if they disable applying updates

note: might be good to automatically disable attempts to apply updates after x number of failure and include ui in the preferences ui to enable / disable when the user doesn't have the ability to apply updates with their user account.

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

>might be good to automatically disable attempts to apply updates after x
>number of failure and include ui in the preferences ui to enable / disable when
>the user doesn't have the ability to apply updates with their user account.

Yeah, my only big concern is how annoying it will get if Firefox keeps saying that it couldn't do something.

A higher level question though: is there anyway to make sure ahead of time that a Firefox updater is running in a privileged process so that it never has to elevate, and everything just transparently works in the background?

Comment 3

[Robert Strong (they/them - no direct email)]

We don't request elevation when it isn't needed currently and this would still be the case. We could create our own service to manage updates or we could use MSI patches on Vista and above which I believe handles elevation for us (I believe they can be configured for silent as well) as long as they are signed with the same cert as the app it is updating but MSI's aren't likely to make the short 3.7 cycle.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

>We could create our own service to manage updates or we could use
>MSI patches on Vista and above which I believe handles elevation for us

Yeah, the approach in this bug is certainly better than what we currently have but, I think our long term goal should be "it always works" :)

Comment 6

[Robert Strong (they/them - no direct email)]

Suggestions from bug 543351 comment #0

The first change is to add an "I have no administrator account" button that
deletes the download (if already downloaded) and suppresses update popups. 
Help -> "Check For Updates ..." should remain available for if their situation
changes.

The second change is to make sure we get the UAC icon over the button to apply
a downloaded update.  Since Windows Vista, the UAC shield icon over a button
has made it clear to users that an action is potentially available, if
administrator account is available.
In order for that to work, we would need a process to apply the update as an
administrator, and wait to restart the browser as the standard user.  Since
there has to be two processes going at once, I'll refer to them as restarter
which is unprivileged, and updater, which will run as an administrator.  The
current updater starts firefox when it is done, so it would have to stop doing
that, but otherwise, it should do what it's always done.  The restarter would
spawn the updater, and initiate a UAC prompt at that time.  It would wait for
the updater to finish, then finally restart firefox (unprivileged).
For standard accounts on pre-UAC systems, the current behavior ("Unable to
Update" dialog) has to stay.  These users might be Type 1 (no admin account),
or they might be 3b (must manually switch accounts), but we have no way to tell
and nothing that can be done about it because of the OS.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 20 votes.
:Amir, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 11

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.