|Feature feature manager=Justin Scott
|Feature lead engineer=Dave Townsend, Wil Clouser
|Feature qa lead=Henrik Skupin
}}
{{FeaturePageBody
|Feature open issues and risks=Some number of extensions out there in the dark matter will be genuinely incompatible and some number of those incompatible extensions will be broken in ways that may not be easy for the user to manage through or around.
|Feature overview=The vast majority of add-ons work from one version of Firefox's switch to rapid releases has been stressful the next without the need for developer maintenance, but under the current system, compatibility information must be updated in order for Firefox to enable the add-on developersfor use. AddFor add-ons hosted on AMO, this is done automatically. However, 75% of add-ons in use are not hosted on AMO , and are especially pained, as they must update therefore a major compatibility every 6 weeks without obstacle for our users. All of the benefit of automatic compatibility bumpingeffort put into each release is simply because Firefox still assumes add-ons will be incompatible between versions, when they usually aren't.
Since the release of We should change Firefox 4 and 5, we've learned s assumption to be that there are many more non-hosted add-ons than we previously thoughtare compatible, mostly those installed by other softwarewith a few exceptions. Whether users make use of these Binary add-ons or not, seeing an incompatible are never compatible between releases and are also the highest risk of negative side effects. Firefox should automatically enable low-risk (non-binary) add-on prevents many users from upgrading to ons in new versions of Firefox, and check AMO for additional compatibility information.
More than 90% When users upgrade to a new version of Firefox, only the add-ons that are compatible from one version of Firefox to the nextactually incompatible should be disabled, and the ones that aren't usually have binary components that will need rest are assumed to be recompiled every releasecompatible. If we change Because Nightly, Aurora, and Beta users will test out the default compatibility assumptionadd-ons for weeks before stable users, we can reduce the action needed should be able to only the very small number of identify and blacklist incompatible add-ons broken before stable users would be affected by the a truly incompatible add-on.|Feature functional spec=''Firefox''When Firefox wants to update to a new releaseversion, rather than 100% of it should determine which add-on developers.ons are incompatible and which will be assumed compatible by looking at the following:
We would move to a model where Firefox assumes 1. If the add-ons are on is already marked as compatible unless they have binary components, with the author has explicitly said to strictly observe stated compatibilitynew version, either in its included install manifest or it is reported to AMO as incompatible through via its updateURL update manifest, the Addadd-on Compatibility Reporterremains enabled.
It's possible and likely we will occasionally enable 2. If the add-ons that don't actually work, but on is not marked as we omit add-ons with binary componentscompatible, this should not cause crashes and users Firefox will simply not have look at its install.rdf to see if the functionality author has opted out of compatible by default and requested strict compatibility mode. If they expecthave, and will complain to the add-on authoris incompatible and should be disabled in the new version of Firefox.
This process would not remove the need for AMO's automatic compatibility bumping3. Next, as it's still preferred Firefox will look for authors to be aware of changes binary components in Firefox and learn about upcoming deprecations and other changesthe add-on.|Feature functional spec=When Firefox needs to determine an If binary components are found, the add-on's compatibility, it is incompatible and should do be disabled in the following:new version of Firefox.
14. If Finally, for all add-ons, Firefox will look at the metadata it received from AMO and the compatibility presented there will override all of the previous checks. AMO may report that the add-on is marked as actually not compatible with the new version, nothing needs to be doneor it may report that it is compatible with the new version. The If there is no compatibility information returned for the particular version of the add-on remains enabledwith the particular version of Firefox, the fallback methods should be used.
2. If Firefox will then inform the user, if necessary, about incompatible add-on is not marked as compatibleons, Firefox will look at its install.rdf or update to see if the author has requested strict compatibility qualification. If they have, new version and automatically enable the add-on is ons that would otherwise be incompatible and disabled.
3. Next, When Firefox will look for binary components in the first enables incompatible add-onons, it should perform a self-test to ensure windows are rendering properly and there are no missing string entities. If binary components are found, Crashing several times in a row or force quitting should cause Firefox to start in safe mode so the problem add-on is incompatible and should can be treated as such (disabled)identified.
4. If the add-on is not marked as compatible and does not contain binary components, Firefox should look at the metadata it received from ''AMO''AMO needs to return compatibility information about the add-on. If the addons, even non-on is not reported as incompatible from AMOhosted ones, it should be enabled as compatiblein its GUID search API responses.
For AMO, this will involve returning We'll need an admin tool where add-on GUIDs can be entered/selected and compatibility information with add-on compatibility versions and versions of Firefox can be saved. We should have an interface to the Add-on Compatibility Reporter reports received in response to metadata API requests, and support that allows for returning information easy compatibility blacklisting of top incompatible add-ons. ''Add-on nonCompatibility Reporter''The ACR should be revamped to better fits its new role of reporting when add-hosted ons are not compatible, rather than when they are compatible. For example, when a user disables an add-onson, it should provide a user with the opportunity to say it's because it doesn't work. And it should look for other signs of incompatibility, similar to the self-tests.
}}
{{FeatureInfo
}}
{{FeatureTeamStatus
|Feature products notes=From the desktop side, we would like this to be prioritized as a P1 and part of achieving "silent update".
}}
