Closed Bug 1705726 Opened 2 years ago Closed 2 years ago

Every time I launch Nightly, Background Update tasks seem to multiply registered.

Categories

(Toolkit :: Application Update, defect)

Firefox 89
Desktop
Windows 10
defect

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox87 --- unaffected
firefox88 --- unaffected
firefox89 --- disabled
firefox90 --- fixed

People

(Reporter: alice0775, Assigned: bytesized)

References

(Blocks 2 open bugs, Regressed 1 open bug, Regression)

Details

(Keywords: nightly-community, regression)

Attachments

(3 files)

Steps to reproduce:

  1. Start multiple Nightly89.0a1 of different BuildIds in different directorys with new profile.
    (Since, testing bugs in Nightly with different BuildIDs)
  2. Check Windows Task Scheduler

Actual Results:
Background Update tasks seem to multiply registered.
When these tasks start simultaneously, there will be a fear that CPU hogging.

Expected results:
I think we need an option(command line option or OS env) to disable task registration.

(In reply to Alice0775 White from comment #0)

Created attachment 9216406 [details]
screenshot of Windows Task Scheduler

Steps to reproduce:

  1. Start multiple Nightly89.0a1 of different BuildIds in different directorys with new profile.
    (Since, testing bugs in Nightly with different BuildIDs)
  2. Check Windows Task Scheduler

Actual Results:
Background Update tasks seem to multiply registered.
When these tasks start simultaneously, there will be a fear that CPU hogging.

Expected results:
I think we need an option(command line option or OS env) to disable task registration.

Hi! This is as expected, but still not ideal, and I did wonder about what would happen with mozregression and friends.

I wouldn't be against an option or environment variable to disable this. Right now you can use the BackgroundAppUpdate policy to disable this.

But there's another possibility I've wondered about. Did you install these Firefox versions with the installer, or did you unarchive a package? If testers generally don't use the installer, we might only background update installed versions by default.

Flags: needinfo?(alice0775)

(In reply to Nick Alexander :nalexander [he/him] from comment #1)

Did you install these Firefox versions with the installer, or did you unarchive a package?
If testers generally don't use the installer, we might only background update installed versions by default.

I download zip file from firefox-ci-tc.services.mozilla.com and archive.mozilla.org.
At least, autoland zip builds create multiple tasks.

Flags: needinfo?(alice0775)

(In reply to Alice0775 White from comment #2)

(In reply to Nick Alexander :nalexander [he/him] from comment #1)

Did you install these Firefox versions with the installer, or did you unarchive a package?
If testers generally don't use the installer, we might only background update installed versions by default.

I download zip file from firefox-ci-tc.services.mozilla.com and archive.mozilla.org.
At least, autoland zip builds create multiple tasks.

Thanks for confirming! This is a data point in favour of only background updating installations installed with the installer. Install :)

Assignee: nobody → ksteuber

I think that we should fix this by checking for the registry key located at HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\MaintenanceService\<MD5(InstallDir)>. This key is written by the installer and, without it, the Maintenance Service will not be used.

Currently, we only check this key when running the updater binary, not from within Firefox (although we may want to consider changing this). Therefore, adding a check using this mechanism will both ensure that the installer was used, and will better verify that the Maintenance Service can actually be used (which is already a requirement for running the Background Update Task).

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #4)

I think that we should fix this by checking for the registry key located at HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\MaintenanceService\<MD5(InstallDir)>. This key is written by the installer and, without it, the Maintenance Service will not be used.

Currently, we only check this key when running the updater binary, not from within Firefox (although we may want to consider changing this). Therefore, adding a check using this mechanism will both ensure that the installer was used, and will better verify that the Maintenance Service can actually be used (which is already a requirement for running the Background Update Task).

I concur: this was the approach I arrived at, too.

Creates nsIUpdateProcessor.serviceRegKeyExists(), which checks for existence the registry key written by the installer that indicates that the current installation can use the Maintenance Service.

Pushed by ksteuber@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4a2629df75a4
Create an interface to determine if the maintenance service registry entry exists r=nalexander
https://hg.mozilla.org/integration/autoland/rev/1454949d2d8b
Only register the Background Update Task if the Maintenance Service key was written by the installer r=nalexander

I'll look into it.

Flags: needinfo?(ksteuber)

Ah, it looks like pathhash.cpp is a Windows-only file, but I included it in the Unified Sources for all platforms. This should be a quick fix.

Pushed by ksteuber@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/33fcfa7ffa8c
Create an interface to determine if the maintenance service registry entry exists r=nalexander
https://hg.mozilla.org/integration/autoland/rev/b7aaea1c650e
Only register the Background Update Task if the Maintenance Service key was written by the installer r=nalexander
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch

Verified fixed with the latest Nightly 90.0a1 (2021-05-13) on Windows 10, 8.1 and 7, no task for the background update is created when using a .zip file. The only thing to mention here is that if you already have a background update task (registered with a build before the fix), an update to the latest build (with the fix) removes instantly the task from Task scheduler only on Windows 10 and 8.1, but not on Windows 7 (it is not multiply though). Nothing happens if the profile/profiles and the Fx folder are removed, manual task deletion is the only way to get rid of it. Worth to mention (although treated in another bug - 1698593) that this behavior does not not apply for the .exe installation (task is removed after an update followed by the browser deletion/uninstallation) and only for the .zip file.

Should we consider uplifting this to Beta?

Flags: needinfo?(ksteuber)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #15)

Should we consider uplifting this to Beta?

This feature's timeline has been pushed back by one cycle. We are now planning to begin enabling it for users on Beta and Release starting in version 90. So I don't think uplifting it to 89 is necessary.

Flags: needinfo?(ksteuber)
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.