1373749 - On Firefox update with new System add-on, reason is APP_STARTUP

Status: NEW

(Toolkit :: Add-ons Manager, enhancement, P3)

Description

[Ian Bicking (:ianbicking)]

We're seeing this with Screenshots, trying to apply an update from 8.0.0 (in Firefox 55) to 10.2.0 (in Firefox 56).

If we create a profile in Firefox 55, with Screenshots 8.0.0 packaged as part of Firefox, then open that profile in a version of Firefox 56 with 10.2.0 installed, then we see a startup reason of APP_STARTUP.  We would expect ADDON_UPGRADE.

Comment 1

[Robert Helmer [:rhelmer]]

I'm pretty sure this is what happens because the add-on is changed out from under the addons manager, and the addons DB no longer matches what's installed at startup. In other words, not a behavior unique to system add-ons - I am seeing the same thing in other install locations as well.

Handling this well doesn't seem important for extensions in the profile, but side-loaded add-ons tend to work this way. I think it'd be fine to change the bootstrap reason for all of these, although it's possible it could break some sideloaded add-on out there. I'd rather not special-case system add-ons if we don't have to though.

Comment 2

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Interesting. It would be great to document the changes to the reason constants contract in the readthedocs page for system addons.

If a system addon has storage in the user's profile, and is removed across versions, would the addon manager notice it's gone and clean up after it? Or would we need to ship a final system addon that clears out storage, then uninstalls itself?

I've thought about this a bit (system addons breaking the typical reason sequence), and can't really think of important edge cases other than those related to profile storage. Are there others I'm missing?

Comment 3

[Robert Helmer [:rhelmer]]

(In reply to Jared Hirsch [:_6a68] [:jhirsch] from comment #2)
> Interesting. It would be great to document the changes to the reason
> constants contract in the readthedocs page for system addons.
> 
> If a system addon has storage in the user's profile, and is removed across
> versions, would the addon manager notice it's gone and clean up after it? Or
> would we need to ship a final system addon that clears out storage, then
> uninstalls itself?
> 
> I've thought about this a bit (system addons breaking the typical reason
> sequence), and can't really think of important edge cases other than those
> related to profile storage. Are there others I'm missing?

I've had similar thoughts :) Maybe I am paranoid, but generally I'd not assume that an add-ons uninstall() will be guaranteed to run... for instance anti-malware vendors have been known to rip out and quarantine XPI files, even those that appear inside the Firefox app directory.

Comment 4

[Andy McKay]

Please let me know if this should be a higher priority or is a concern for 57.