Closed Bug 1552853 Opened 1 year ago Closed 1 year ago

Update downloads get stuck at 'Applying update' state in the UI (updates continue to work) when Mozilla Maintenance Service is disabled

Categories

(Toolkit :: Application Update, defect, P1)

68 Branch
All
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla69
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- unaffected
firefox67 --- unaffected
firefox68 + verified
firefox69 --- verified

People

(Reporter: atrif, Assigned: robert.strong.bugs)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached image bitsaplyingstate02.gif

Affected versions

  • Firefox 68.0b1 (20190513111358)
  • Firefox 68.0a1 (20190518102559)

Affected platforms

  • Windows 10x64
  • Windows 7x64

Preconditions

  • Install an older version of Firefox ex (Firefox 68.0b1 (20190513111358) or Firefox 68.0a1 (20190511220902)).
  • Disable Mozilla Maintenance Service.

Steps to reproduce

  1. Launch Firefox and open browser console.
  2. Wait for the update download to complete and wait for about 10 seconds after completion.
  3. Click the about Firefox button from the Hamburger > Help menu.

Expected result

  • The message “Restart to update Firefox” is displayed.

Actual result

  • On Nightly builds - The “Restart to update” message appears in the hamburger menu and is accessible, but accessing the Help menu shows the “Applying update...” in an endless loop state.
  • On Beta/Deved builds - The “Restart to update” message does not appear in the hamburger menu and accessing the Help menu displays the “Applying update...” in an endless loop state.

Regression Range

Additional Notes

  • Attached a screen recording with this issue.
  • Restarting or closing the browser makes UAC appear and if “Yes” option is clicked, the browser is updated.
  • The issue is reproducible using both nsIIncrementalDownload and BITS.
Attached file update_log.txt

Hi Kirk,

It is possible that this may have been caused by the fix from bug 1546627.

Can you please have a look?

Thanks!

Flags: needinfo?(ksteuber)
Has Regression Range: --- → yes
Has STR: --- → yes
Priority: -- → P2
Summary: Update downloads get stuck at “Applying update” state when Mozilla Maintenance Service is disabled → Update downloads get stuck at “Applying update” state in the UI (updates continue to work) when Mozilla Maintenance Service is disabled

Thanks, I'll take this.

Flags: needinfo?(ksteuber)
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Summary: Update downloads get stuck at “Applying update” state in the UI (updates continue to work) when Mozilla Maintenance Service is disabled → Update downloads get stuck at 'Applying update' state in the UI (updates continue to work) when Mozilla Maintenance Service is disabled
Priority: P2 → P1

Fixes the case reported where disabling the maintenance service caused the UI to display Applying due to the update staging failure.
Added new error codes for the two cases where pending was written to the update.status file when staging failed.
Added code to UpdateService.jsm to set the update.status to pending when either of the two new error codes are in the update.status file.
Added two new tests that verify the UI and simulate the failure condition in updater.cpp.

Flags: in-testsuite+
Pushed by rstrong@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ebeb4133719f
Fix the update UI so it displays restart when it should when update staging fails. r=mhowell
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Comment on attachment 9066783 [details]
Bug 1552853 - Fix the update UI so it displays restart when it should when update staging fails. r=mhowell

Beta/Release Uplift Approval Request

  • User impact if declined: Clients can get into a state where the UI shows Applying instead of Restart when update staging fails due to the maintenance service being disabled.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: From comment #0

Preconditions

Install an older version of Firefox ex (Firefox 68.0b1 (20190513111358) or Firefox 68.0a1 (20190511220902)).
Disable Mozilla Maintenance Service.

Steps to reproduce

Launch Firefox and open browser console.
Wait for the update download to complete and wait for about 10 seconds after completion.
Click the about Firefox button from the Hamburger > Help menu.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): There were 2 instances where the updater set the update to pending when there was an error so it would be instead applied on restart. This patch sets those two cases to an error and it changes UpdateService.jsm to handle these two errors like it already does for other errors.
  • String changes made/needed: None
Attachment #9066783 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Hello,
I just want to point out that we can't use the same builds from preconditions. We need 2 fixed builds to successfully verify the bug. The same conditions apply on Nightly and Beta. I will begin testing when there are available 2 builds containing the fix. Or is there any other way to test this?
Thank you!

Hello,

The issue is verified when updating from Firefox 69.0a1 (20190524214959) to Firefox 69.0a1 (20190526211422) using both nsIIncrementalDownload and BITS on Windows 10 x64 and Windows 7 x64.

Comment on attachment 9066783 [details]
Bug 1552853 - Fix the update UI so it displays restart when it should when update staging fails. r=mhowell

updater fix, approved for 68.0b5

Attachment #9066783 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

The issue is verified when updating from Firefox 68.0b5 (20190527103257) to Firefox 68.0b6 (20190529145824) using both nsIIncrementalDownload and BITS on Windows 10 x64 and Windows 7 x64.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Regressed by: 1546627
You need to log in before you can comment on or make changes to this bug.