488798 - Hidden prefs to check minVersion and maxVersion of extensions should be separate

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Tony Mechelynck [:tonymec]]

There already exists a hidden pref, extensions.checkCompatibility (Boolean), to auto-disable (omitted or true) or not (false) addons whose minVersion and maxVersion don't span the current application version.

However, even though I've often seen addons whose maxVersion was underestimated, I have yet to see even one whose minVersion was overestimated.

Therefore I move that extensions.checkCompatibility, when set to false, should only disable addons whose maxVersion is lower than the current app version.

If desired, an additional hidden pref could be added (or not) to avoid auto-disabling addons whose minVersion is higher than the current app version.

I believe that such a change would involve low risk and high added stability/security (especially if a user tries a new version of the application, possibly auto-upgrades addons at startup, then finds the new version wanting and goes back to an earlier version).

Comment 1

[Tony Mechelynck [:tonymec]]

oops... comment #0 §3 above: when set to false, should only avoid disabling...

Comment 2

[Robert Strong (they/them - no direct email)]

I'm not saying this shouldn't be done but this hidden pref was specifically added for testing and changing it is "at your own risk". I personally don't think this change is all that valuable and people will just resort to using nightly tester tools when this no longer enables their extensions.

Do you have any urls to examples where this would have provided value?

Comment 3

[Tony Mechelynck [:tonymec]]

(In reply to comment #2)
[...]
> Do you have any urls to examples where this would have provided value?

Sure. I happen to be one of the (last, maybe) users of BonEcho aka Firefox 2. Now that Fx2 won't ever be built anymore, I thought that it was maybe time to upgrade to the next version; so I downloaded a Fx 3.0.x build and installed it (without having first backed up my profile -- foolish of me, maybe, but I thought that by now, Fx 3.0's "growing pains" would be past). However, almost everything stopped working: most cookies apparently lost, theme reset to default, most extensions not working (even though I have extensions.checkCompatibility set to false), and more. So I went back in haste (temporarily, I suppose) to BonEcho, but everything was still not working. What finally made it work (after several attempts at milder remedies) was closing Firefox, loading the "Profile folder - Firefox" page of the Mozillazine KB in Konqueror, and removing from my profile everything that was "Firefox 3.0 and later" and most of the stuff labeled "Can be safely deleted to fix some problems". But I still had some extensions (maybe 10% of 50 or so) which Fx3 had just upgraded at startup, and which needed to be, first, found out, and then, downgraded. If BonEcho had auto-disabled them the "find them out" task would have been trivial. Of course BonEcho won't ever get this RFE, but I want my life to be easier when someday I upgrade from Fx 3.0 to 3.1 or from 3.x to 4.x, even if I get the same kind of problems. So if this RFE ever gets applied, I'll be sure to set my prefs so that toolkit apps obey addons' minVersion but not (at my own risk, I know) the maxVersion.

(Some day soon -but not today- I'll try loading Fx3 again, since maybe my profile cleanup was good enough to cure the problem, but I'll back up my profile first.)

----

Philip, Mel, you are the people whose opinion I value most when it comes to extensions: what do you think of this RFE?

Comment 4

[Robert Strong (they/them - no direct email)]

Are there any examples from other people dealing with this scenario that you can link to (perhaps on mozillazine or elsewhere)?

Comment 5

[Philip Chee]

> So I went back in haste
> (temporarily, I suppose) to BonEcho, but everything was still not working.
Presumably "everything" refers to your extensions only right? I'd think your cookies etc would continue to work in Bon Echo.

> What finally made it work (after several attempts at milder remedies)
I'd think just deleting the extensions.rdf file in your 2.0 profile and restarting would have re-enabled all your Bon Echo compatible extensions.

> Philip, Mel, you are the people whose opinion I value most when it comes to
> extensions: what do you think of this RFE?

1. I think your situation is an edge case.

2. Adding this pref would just allow the average user (not you) to shoot themselves in the foot in yet more ways and unlike you they wouldn't know how to go to the mozillazine knowledgebase to learn how to repair their profiles.

3. I think from Firefox 3.0 onwards, just deleting all the three extensions.* files should fix any similar problems. I would not be surprised if this procedure was already detailed in SUMO and the mozillazine knowledgebase.

4. I'm not exactly the best person to ask since I regularly test against nightly trunk builds of Firefox, SeaMonkey and Thunderbird and so I've learnt a long long time ago to back up all my profiles twice a day every day to multiple locations. In fact I think it's time I started putting my profiles under version control with Mercurial.

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to comment #5)
> Presumably "everything" refers to your extensions only right? I'd think your
> cookies etc would continue to work in Bon Echo.

Extensions still not working (including TabMixPlus's "session manager" and "flowing tabs" functionalities), profile still set to default instead to the one which had "use this profile" greyed-out in the addons manager... cookies I'm not sure.

> 
> > What finally made it work (after several attempts at milder remedies)
> I'd think just deleting the extensions.rdf file in your 2.0 profile and
> restarting would have re-enabled all your Bon Echo compatible extensions.

Maybe; but if the reason of the Fx3 failure was an older try-and-comeback with an older version of Fx3, this cleanaway of everything "Fx3 and later" will (I hope) force a clean re-migrate from whatever BonEcho uses to *.sqlite etc. the next time.

> 
> > Philip, Mel, you are the people whose opinion I value most when it comes to
> > extensions: what do you think of this RFE?
> 
> 1. I think your situation is an edge case.

Hm, maybe, but I'm sure I'm not the first (nor the last) to go back to a previous version after having tried a newer one and been horrified by the results.

> 
> 2. Adding this pref would just allow the average user (not you) to shoot
> themselves in the foot in yet more ways and unlike you they wouldn't know how
> to go to the mozillazine knowledgebase to learn how to repair their profiles.

Adding a pref I'm not sure; what I'm advocating most strongly is restricting the action of extensions.checkCompatibility=false to the maxVersion only. And still hidden of course.

> 
> 3. I think from Firefox 3.0 onwards, just deleting all the three extensions.*
> files should fix any similar problems. I would not be surprised if this
> procedure was already detailed in SUMO and the mozillazine knowledgebase.

That's goos news; I guess I should go and search for those pages.

> 
> 4. I'm not exactly the best person to ask since I regularly test against
> nightly trunk builds of Firefox, SeaMonkey and Thunderbird and so I've learnt a
> long long time ago to back up all my profiles twice a day every day to multiple
> locations. In fact I think it's time I started putting my profiles under
> version control with Mercurial.

:-) Twice a day is too often for my present needs, and version control even more. I conduct some tests from time to time with Minefield, but on a separate profile; but this was different: version changeover on my "day-to-day" profile (with about 50 extensions, 150 tabs, etc.). Next time I'll back it up (and you bet that backup won't be needed? Well, better safe than sorry.)

Comment 7

[Dave Townsend [:mossop]]

I don't think we can invest any more time or code complexity to this setting than is necessary. The preference is at your own risk, I can see the point for your limited case but it just isn't worth the time to fix that issue.