Closed Bug 1567077 Opened 4 months ago Closed 4 months ago

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

Categories

(Toolkit :: Application Update, defect, P1)

68 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 69+ fixed
firefox68 --- wontfix
firefox69 + fixed
firefox70 + fixed

People

(Reporter: bugzilla, Assigned: rstrong)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

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)

Component: Untriaged → Application Update
Product: Firefox → Toolkit

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.

Assignee: nobody → robert.strong.bugs
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P2
Regressed by: 1458314

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.

Attachment #9081089 - Attachment description: Bug 1567077 - don't try to updates when the update.status file is read only. r=bytesized → Bug 1567077 - don't try to update when the update.status file is read only. r=bytesized
Pushed by rstrong@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/28fc56e3b8b5
don't try to update when the update.status file is read only. r=bytesized
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

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

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

Flags: needinfo?(robert.strong.bugs)

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

Flags: needinfo?(robert.strong.bugs)

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
Attachment #9084825 - Flags: review+
Attachment #9084825 - Flags: approval-mozilla-esr68?
Attachment #9084825 - Flags: approval-mozilla-beta?
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.
Attachment #9084825 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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 on attachment 9084825 [details] [diff] [review]
patch for beta and esr 68

Approved for 68.1esr.
Attachment #9084825 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
You need to log in before you can comment on or make changes to this bug.