413153 - If an extension exists under both the app folder and the profile (meaning the latter overrides the former), and the global version gets upgraded to an equal or later version than the latter, the user should be given the opportunity to uninstall the latter

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Tony Mechelynck [:tonymec]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.9b3pre) Gecko/2008011901 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.9b3pre) Gecko/2008011901 SeaMonkey/2.0a1pre

This also applies to version 2.0a1 ("and later") of SeaMonkey and, I think, to Thunderbird.

See bug 300967 and http://wiki.mozilla.org/ChatZilla:Suiterunner#appManaged about how an upgrade for a global extension might get instazlled in the profile, with the user not necessarily aware of the duplication.

If (e.g. by installing the next app nightly) the app-global version of that extension becomes equal or later than the one in the profile, the user is currently not made aware of the fact and the duplication persists (with the version in the profile overriding the one under the installdir). IMHO the user should (at the minimum) be made aware of the fact; ideally, I'd like the extension-update popup to come up at next startup, offering to uninstall the (now duplicate or even obsolete) version of the extension in the profile.

Reproducible: Always

Steps to Reproduce:
1. See above.
2.
3.

Actual Results:  
See above.

Expected Results:  
See above.

Comment 1

[Justin Wood (:Callek)]

confirming, as I at least would also like this, (and did not find a dupe).

Nominating wanted (I don't see how this would affect Firefox dot releases)

Comment 2

[Justin Wood (:Callek)]

assuming too risky for 1.9.0 stable branch... nominating wanted for 1.9.1

Comment 3

[Justin Wood (:Callek)]

clearning wanted 1.9.1 adding wanted1.9.2 request (though late in game, should actually be wanted1.9.3/wanted-next but I can't set either)

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Dave, now that we install app-shipped add-ons into the user profile, can we mark this bug as fixed?

Comment 5

[Justin Wood (:Callek)]

(In reply to comment #4)
> Dave, now that we install app-shipped add-ons into the user profile, can we
> mark this bug as fixed?

We don't (yet) ignore app-shipped add-ons from staying app-shipped and thus FORCE profile-shipping. I'm not sure if we even want to. But I do bet this could be WONTFIX though. It surely is not fixed, however.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

With bug 474289 fixed any new app-shipped extensions which has a higher version number as the one in the profile will be automatically installed into the users profile. Given that the profile always has the most recent version of the extension installed.

If I miss something, it's because I'm a bit confused by the original comment and summary.

Comment 7

[Dave Townsend [:mossop]]

The issue here is that users can have multiple versions of the same extension installed in the profile, the application and the other global install locations. The suggestion is that if the profile version is older then the user ought to be able to choose to use the newer version.

I suspect this isn't something we'd put in the users hands but it is worth thinking about switching to a model where the newest compatible version is always used.

Comment 8

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.