XPIProvider unnecessarily scans for all scopes at the second startup
Categories
(Toolkit :: Add-ons Manager, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox85 | --- | fixed |
People
(Reporter: robwu, Assigned: mixedpuppy)
Details
Attachments
(1 file)
scanForChanges
should only scan in every location right after a new install or update. Unexpectedly, it also scans for changes at the second start-up (but not after the third, fourth, etc.).
-
At the first run after a new install or browser update,
aAppChanged
is notfalse
, andscanForChanges(aAppChanged === false)
is equivalent toscanForChanges(false)
. -
Because the
ignoreSideloads
parameter isfalse
, the right-hand-side ofignoreSideloads && !(loc.scope & gStartupScanScopes
never runs, so thegStartupScanScopes
getter that is responsible for setting theextensions.lastAppBuildId
pref is not triggered. All scopes are scanned, as expected. -
At the next start-up of the same browser version,
aAppChanged
isfalse
, andscanForChanges(true)
is called. Now thegStartupScanScopes
getter is triggered, and since theextensions.lastAppBuildId
pref had not been set before, the getter thinks that the build ID has changed and forces a scan of all scopes.
The last part of step 3 is unexpected: The browser has really not been updated (any changes should already have been detected at step 1), so there should not be a forced scan of all scopes.
Reproduced in Firefox 66.0.3 (originally observed in bug 1549129) and Firefox 69.0a1 buildID 20190523044159.
Updated•5 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Updated•3 years ago
|
Pushed by scaraveo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c19e5f49c88f fix setting lastAppID pref during AOM startup and scanForChanges r=robwu
Comment 3•3 years ago
|
||
bugherder |
Description
•