1567077 - firefox doesn't open in non-administrative sessions when an update is pending in an administrative session and the browser hasn't been opened yet

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P1)

Description

[bugzilla]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

update has been downloaded and firefox has only been closed in an administrative account on a terminalserver

Actual results:

non-adminstrative accounts on the terminalserver weren't able to open firefox until the administrator opened it so that the pending update will be installed

Expected results:

non-administrative accounts should be able to use firefox with the pre-updated status instead of waiting for an admin to complete the update (like it was before)

Comment 1

[bugzilla]

it's quite a bit different.

the local administrator on the terminalserver has firefox opened and seems to be the session which does the update automatically.

the domain administrator is also on the terminalserver and has firefox closed. when this error occurs, an administrator (we did it only with the domain administrator, yet) has to open firefox before the users have been able to open it after the pending update.

Comment 2

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

Attachment: Bug 1567077 - don't try to update when the update.status file is read only. r=bytesized

When checking for an update during startup, open the update.status file with read and write access so repeated update attempts are prevented when there is only read access to the update.status file.
When loading the active-update.xml file after startup, open it with both read and write access so the active-update.xml isn't loaded when there is only read access and the client will still receive manual update notifications.
On Windows, when opening the active-update.xml file with both read and write access fails attempt to fix the update directory permissions.
When checking if it is possible to apply updates, first check for write access to the update directory so OS X no longer always returns true and Windows no longer always returns true when the maintenance service can be used.
Sets security.turn_off_all_security_so_that_viruses_can_take_over_this_computer to true in the app update xpcshell tests so Cu.isInAutomation is true when running the tests.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/28fc56e3b8b5
don't try to update when the update.status file is read only. r=bytesized

Comment 4

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/28fc56e3b8b5

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Sounds like a bug we want to fix in Fx69/68.1esr. Please nominate for Beta & ESR68 approval when you're comfortable doing so.

Comment 6

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Robert, since 69 is marked as affected, could you please nominate an uplift of this fix to beta69? Thanks!

Comment 7

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

Will do after this has baked a couple of more days on nightly

Comment 8

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

Attachment: patch for beta and esr 68

Beta/Release Uplift Approval Request

• User impact if declined: Firefox won't open in non-administrative sessions when an update is pending in an administrative session and the browser hasn't been opened yet
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It has been on Nightly for over a week with no reported regressions
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Firefox won't open in non-administrative sessions when an update is pending in an administrative session and the browser hasn't been opened yet
• User impact if declined: Firefox won't open in non-administrative sessions when an update is pending in an administrative session and the browser hasn't been opened yet
• Fix Landed on Version: 70
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It has been on Nightly for over a week with no reported regressions
• String or UUID changes made by this patch: None

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9084825 [details] [diff] [review]
patch for beta and esr 68

Approved for 69.0b14. Let's let it bake there a bit before uplifting to ESR too.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/596c8cf54696

Comment 11

[Ryan VanderMeulen [:RyanVM]]

The Beta patch was missing the new test, which was causing bustage.

Landing the new test:
https://hg.mozilla.org/releases/mozilla-beta/rev/4f6990df2347

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9084825 [details] [diff] [review]
patch for beta and esr 68

Approved for 68.1esr.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/cff9160d2b75