Canmove, confirm, emeritus
1,043
edits
Changes
no edit summary
When users upgrade to a new version of Firefox, only the add-ons that are actually incompatible should be disabled, and the rest are assumed to be compatible. Because Nightly, Aurora, and Beta users will test out the add-ons for weeks before stable users, we should be able to identify and blacklist incompatible add-ons before stable users would be affected by a truly incompatible add-on.
|Feature users and use cases=For users without binary add-ons, we hope this will eliminate the vast majority of compatibility issues between rapid releases and allow for silent updates.
|Feature non-goals=This plan is not trying to solve the issue of binary compatibility between releases.
|Feature functional spec='''Firefox'''<br/>
When Firefox wants to update to a new version, it should determine which add-ons are incompatible and which will be assumed compatible by looking at the following:
When Firefox first enables incompatible add-ons, it should perform a self-test to ensure windows are rendering properly and there are no missing string entities. Crashing several times in a row or force quitting should cause Firefox to start in safe mode so the problem add-on can be identified.
'''AMO'''<br/>
AMO needs to return compatibility information about add-ons, even non-hosted ones, in its GUID search API responses.
We should have an interface to the Add-on Compatibility Reporter reports that allows for easy compatibility blacklisting of top incompatible add-ons.
'''Add-on Compatibility Reporter'''<br/>
The ACR should be revamped to better fits its new role of reporting when add-ons are not compatible, rather than when they are compatible. For example, when a user disables an add-on, 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.
}}
