canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,043
edits
Features/Add-ons/Add-ons Default to Compatible: Difference between revisions
Features/Add-ons/Add-ons Default to Compatible (view source)
Revision as of 01:13, 22 September 2011
, 22 September 2011no edit summary
No edit summary |
No edit summary |
||
| Line 19: | Line 19: | ||
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. | 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 non-goals=This plan is not trying to solve the issue of binary compatibility between releases. | ||
|Feature functional spec='''Firefox''' | |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 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: | ||
| Line 35: | Line 36: | ||
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. | 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''' | '''AMO'''<br/> | ||
AMO needs to return compatibility information about add-ons, even non-hosted ones, in its GUID search API responses. | AMO needs to return compatibility information about add-ons, even non-hosted ones, in its GUID search API responses. | ||
| Line 42: | Line 43: | ||
We should have an interface to the Add-on Compatibility Reporter reports that allows for easy compatibility blacklisting of top incompatible add-ons. | 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''' | '''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. | 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. | ||
}} | }} | ||