Closed Bug 570033 Opened 9 years ago Closed Last year
Expose add-on compatibility checking mode in Install
We've seen a couple bugs filed lately involving the browser not exposing whether it's enforcing add-on compatibility checking or not. 1. AMO lets users install incompatible add-ons after a warning in case they have disabled compatibility checking. Users that haven't disabled checking assume they can override the install, but then get a Firefox error and are confused about why we let them do it anyway. 2. The Discovery Pane only shows featured/popular add-ons that are compatible with the browser version, which is few for trunk users. If we included the compatibility checking status with the discovery pane load parameters, we could know whether to return all add-ons. I think the first case is more important, and would likely involve adding an InstallTrigger method that would say whether the add-on's compatibility will be checked upon install. If it will, AMO wouldn't let the user try to override it. The second is slightly more controversial in that we'd be offering incompatible add-ons as featured to these users who have disabled compatibility checking. As we would still warn that they are incompatible on the install buttons, I don't think this is a danger to normal users as they'd have to disable compatibility checking AND ignore the incompatibility warning.
In reply to comment #0: I override compatibility checking, and my take on this matter is that I don't need, or even want, to be shown "Featured" addons which don't boast support of my version in the addon discovery pane, no matter how few my results become. If I want to see which addons are Featured for other versions than mine, or even other applications than mine, I can always browse AMO and possibly use the "Advanced Search" feature there. (Of course, if I browse for featured Firefox extensions using SeaMonkey, any version compatibility becomes a moot point.) If I decide to install a particular addon in spite of an incompatibility, it's my responsibility, and if the incompatible addon is a cause of malfunction I shouldn't whine in anyone's jacket, or, worse, throw a flamewar against anyone, but either disable (or uninstall) the malfunctioning addon, or (if the bug is 'minor' in Bugzilla terminology and I need other functions of that same addon) maybe live with it and/or inform the author that "this great addon could work even better with SeaMonkey-trunk if only...". OTOH, if someone does *not* override the compatibility check (which might be either because he doesn't know about the option, or because he knows but doesn't want to exercise it), I agree that he should not be proposed to "Install anyway". Maybe let him know clearly that it is no use triggering the install of an incompatible addon, because his browser won't allow the install to complete. As icing on the cake (and if it isn't yet done this way) propose an app upgrade if it's a minVersion incompatibility, or give a message like "This addon has not yet been updated to support your browser version" if it's a maxVersion incompatibility. I'm leaving on the side for the moment the case of when the current browser is simply not supported (like trying to install into SeaMonkey an addon which boasts support of Firefox, but neither SeaMonkey nor Toolkit), since in that case even after setting extensions.checkCompatibility.<version> to true the install will still fail. _Downloading_ the addon should still be possible (except maybe if the addon's license prohibits inspection and reverse-engineering, but is this enforceable of an xpi?).
oops... setting extensions.checkCompatibility.<version> to *false*
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
Summary: Consider exposing add-on compatibility checking status of the browser → Expose add-on compatibility checking mode in InstallTrigger
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: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.