Suggestion of changes to the add-ons manager
By glazou on Monday 18 July 2011, 22:38 - Mozilla - Permalink
it's everywhere. Add-ons broken (hear disabled) by faster updates of Firefox are a pain for users. I think Mozilla could prevent this implementing the rather simple following rules:
- if an add-on's maxVersion does not match any more Firefox's version, show an alert/notification/arrowbox offering to disable the version compatibility check for that add-on, enabling immediately the add-on for immediate use ; it should be a real warning box, of course...
- if an add-on with compatibility check disabled is suddenly updated or auto-updated to a version matching Firefox, re-enable compatibility checking
- modify the add-ons manager to make the above clearer and make it easier to enabled/disable the compatibility checking for a given add-on (there is currently no UI for that and that's really lacking)
- when auto-update of add-ons is performed, let the user know if he/she has add-ons that are enabled only because their compatibility check is disabled
This is not an optimal solution, it's a short-term compromise to stop making users angry, in particular in the case of an add-on not served by AMO (and there are plenty of them) that could easily survive a maxVersion bump. Opinions?
Comments
In order to make that happen, first AMO has to solve the problem of hundreds of addons that are stuck even farther back than Firefox 4.
AMO has a policy of never removing add-ons. I think that's a bad policy.
They should go through and clean up add-ons that are no longer compatible.
Opinions? I've been running on trunk since I don't know when, and of course there has always been a lag, so I've had compatibility auto-disable off for a long time (checking is still done, but its result is only a warning in the addons manager, not an auto-disable). I know that it is dangerous and that disabling misbehaving addons is my responsibility. But maybe (even before Gecko 2) two-thirds of my add-ons or more suffer from what jonoscript calls "paperwork incompatibility". They work perfectly, and I don't want to be bothered with ATTENTION!!! ARE YOU SURE??? popups all over the place whenever I update an extension, or for all of them when I update the app every month-and-a-half.
However I understand that for the rank-and-file newbie user those popups would be a useful safeguard. So IMHO they should depend on a preference.
Good suggestion as usual
I think something along these lines needs to be done but
1) What you suggest wouldn't work for add-ons that contain XPCOM binary components. (JS and jsctypes binary components could work.)
2) This would probably need to be coupled with the crash reporter so that if the app starts crashing at startup, the force-enabled add-ons a disabled or if the app starts crashing later (i.e. not at startup), the user is at least reminded of force-enabled add-ons.
Also, the list at https://bugzilla.mozilla.org/show_b... makes it look like that a big part of the current problem is due to incompatible extensions that have XPCOM binary components and, as mentioned above, your solution wouldn't work in that case (because mismatching vtables would be such a crashy gamble).
Mike, I don't disagree,but see also https://addons.mozilla.org/en-US/fi... (click View Compatibility Report, then Detailed Report; no way to deep link). It appears that as far as Firefox 5 goes, AMO-hosted add-ons are in a pretty good shape and the big issue are add-ons that don't come from AMO.
Glazou, a while back, even before all that rapid release discussion came up, I had proposed an exception mechanism for add-ons in the same style as we have it for SSL certificates. That would solve the first two points of your proposal in one go (as the exception to enable compatibility would only apply to this version of the add-on on this version of Firefox).
In general, I'm pretty sure we'll need to do something like that, though - maybe in conjunction with a crowdsourcing model that just bumps up compatibility on AMO if enough people add an exception (and have not disabled an option to inform AMO of this).
Tout à fait d'accord. La politique du fait accompli de Mozilla sur les adds-ons est particulièrement irritante.
@Robert - the crowdsourcing suggestion that you mention could be powered by the Compatibility Reporter add-on perhaps. The version would be bumped if enough users reported it working on that particular version.
My suggestion is that, instead of having implemented the version-specific compatibility checking preferences, what should have been done is this. Implement a subroutine that checks to see if compatibility-checking has been disabled. If it has been disabled, display a warning dialog to remind the user that they have disabled compatibility-checking and have the user confirm if they want to continue having it disabled.
At the time that version-specific compatibility-checking was being implemented, the "thought" was that users may have forgotten that they had disabled the preference. By choosing the method they did, they have forced users who wish to continue to have compatibility-checking disabled to jump through hoops (or install Addon Compatibility Reporter) to do so. But, since that was before the change to rapid major update scenario, users were not facing this (now) problem very often.
In hindsight, it appears that by trying to fix something that was not really broken, more problems have been generated that did not need to be created in the first place.
As well as crowdsourcing how many people have enabled "incompatible" extensions, it would be a good idea to see how many then had to disable them again.