Closed Bug 413153 Opened 17 years ago Closed 6 years ago

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

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED INACTIVE
Tracking Status
status2.0 --- wontfix

People

(Reporter: tonymec, Unassigned)

Details

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.
Whiteboard: [also Tb & Sm-trunk]
Version: unspecified → Trunk
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)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x?
assuming too risky for 1.9.0 stable branch... nominating wanted for 1.9.1
Flags: wanted1.9.0.x? → wanted-firefox3.1?
Product: Firefox → Toolkit
Whiteboard: [also Tb & Sm-trunk]
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)
Flags: wanted1.9.1? → wanted1.9.2?
status2.0: --- → ?
Flags: wanted1.9.2?
Dave, now that we install app-shipped add-ons into the user profile, can we mark this bug as fixed?
(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.
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.
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.
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.