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

NEW
Unassigned

Status

()

P3
normal
a year ago
a year ago

People

(Reporter: ianbicking, Unassigned)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(firefox57 wontfix)

Details

(Reporter)

Description

a year ago
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.
(Reporter)

Updated

a year ago
Blocks: 1372310
(Reporter)

Updated

a year ago
No longer blocks: 1372310
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.
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?
(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

a year ago
Please let me know if this should be a higher priority or is a concern for 57.
status-firefox57: --- → wontfix
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.