Closed Bug 1658711 Opened 10 months ago Closed 9 months ago

[Windows 7] WDBA task gets deleted from task scheduler when updating Firefox beta

Categories

(Toolkit :: General, defect)

Product:
Toolkit
Component:
General
Platform:
Desktop
Windows 7
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
81 Branch
Tracking Flags:
Tracking Status
firefox80 --- wontfix
firefox81 --- verified

People

(Reporter: csasca, Assigned: bytesized)

Details

(Keywords: regressionwindow-wanted)

Attachments

(2 files)

wdba task deleted.gif
4.06 MB, image/gif
Details
Bug 1658711 - Ensure that the PostUpdate task is called reliably r=mhowell
47 bytes, text/x-phabricator-request
Details | Review
Attached image wdba task deleted.gif —

Affected versions

  • Firefox 80.0b7

Affected platforms

  • Windows 7

Steps to reproduce

  1. Install for example Firefox 80.0b2
  2. See that the task for WDBA is present in task scheduler
  3. Launch Firefox and update it

Expected result

  • WDBA task is still present in task scheduler

Actual result

  • WDBA task gets deleted

Regression range

  • Will see for a regression

Additional notes

  • The issue can be seen in the attachment
  • Windows 10 is not affected by this issue
  • This happens when updating from 80.0b2 to 80.0b7

Suggested severity

  • s1 or S2

I've reproduced the problem. However, the command line register-task and unregister-task commands seem to work fine, suggesting that the problem is not within the WDBA binary. I'm working on getting a debugger connected so I can verify. Assuming that this is the case, it probably points to a bug in our NSIS code, which is unfortunate because it is quite difficult to debug.

Assignee: nobody → ksteuber
Severity: -- → S2
Has Regression Range: --- → no
Has STR: --- → yes

Huh, so I can no longer reproduce this problem for reasons that are a mystery to me. However, I have a pretty good idea of one way this could happen. I'll fix that bug, and I guess we'll see if the problem goes away. I'm not sure what else I can do at the moment.

There is a way to reproduce the bug I found. And it is possible for Firefox to basically get into this state on its own, so it's possible that this is the reported problem. It should be reproducible by unchecking the "Use a background service to install updates" box in the Update section of the settings page. The remaining STR are the same.

The PostUpdate task must always be called as the unelevated user, even if we didn't use the service, in order to ensure that we register the WDBA. Additionally, the PostUpdate task should always be run synchronously so that the elevated and unelevated PostUpdate tasks are guaranteed to run in order. This is important since the elevated PostUpdate unregisters the task and the unelevated PostUpdate re-registers it.

Pushed by ksteuber@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3822966f8096
Ensure that the PostUpdate task is called reliably r=mhowell

https://hg.mozilla.org/mozilla-central/rev/3822966f8096

Status: NEW → RESOLVED
Closed: 9 months ago
status-firefox81: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch

Did two updates: One from 80.0 and one from 81.0b4, both to RC2 81.0 and the task was updated successfully.

Status: RESOLVED → VERIFIED
status-firefox81: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.