Features/Add-ons/Add-ons Default to Compatible: Difference between revisions
mNo edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
|Feature feature manager=Justin Scott | |Feature feature manager=Justin Scott | ||
|Feature lead engineer=Dave Townsend, Wil Clouser | |Feature lead engineer=Dave Townsend, Wil Clouser | ||
}} | }} | ||
{{FeaturePageBody | {{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 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=Firefox | |Feature overview=The vast majority of add-ons work from one version of Firefox to 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 for use. For add-ons hosted on AMO, this is done automatically. However, 75% of add-ons in use are not hosted on AMO, and are therefore a major compatibility obstacle for our users. All of the compatibility effort put into each release is simply because Firefox still assumes add-ons will be incompatible between versions, when they usually aren't. | ||
We should change Firefox's assumption to be that add-ons are compatible, with a few exceptions. Binary add-ons are never compatible between releases and are also the highest risk of negative side effects. Firefox should automatically enable low-risk (non-binary) add-ons in new versions of Firefox, and check AMO for additional compatibility information. | |||
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 functional spec=''Firefox'' | |||
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: | |||
1. If the add-on is already marked as compatible with the new version, either in its included install manifest or via its updateURL update manifest, the add-on remains enabled. | |||
2. If the add-on is not marked as compatible, Firefox will look at its install.rdf to see if the author has opted out of compatible by default and requested strict compatibility mode. If they have, the add-on is incompatible and should be disabled in the new version of Firefox. | |||
3. Next, Firefox will look for binary components in the add-on. If binary components are found, the add-on is incompatible and should be disabled in the new version of Firefox. | |||
4. 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 actually not compatible with the new version, or it may report that it is compatible with the new version. If there is no compatibility information returned for the particular version of the add-on with the particular version of Firefox, the fallback methods should be used. | |||
Firefox will then inform the user, if necessary, about incompatible add-ons, or update to the new version and automatically enable the add-ons that would otherwise be incompatible. | |||
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 needs to return compatibility information about add-ons, even non-hosted ones, in its GUID search API responses. | |||
We'll need an admin tool where add-on GUIDs can be entered/selected and compatibility information with add-on versions and versions of Firefox can be saved. | |||
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'' | |||
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. | |||
}} | }} | ||
{{FeatureInfo | {{FeatureInfo | ||
| Line 45: | Line 51: | ||
}} | }} | ||
{{FeatureTeamStatus | {{FeatureTeamStatus | ||
|Feature products notes=From the desktop side, we would like this to be prioritized as a P1 and part of achieving "silent update". | |Feature products notes=From the desktop side, we would like this to be prioritized as a P1 and part of achieving "silent update". | ||
}} | }} | ||
Revision as of 22:17, 21 September 2011
Status
| Add-ons Default to Compatible | |
| Stage | Draft |
| Status | ` |
| Release target | Firefox 9 |
| Health | OK |
| Status note | Soliciting feedback. |
{{#set:Feature name=Add-ons Default to Compatible
|Feature stage=Draft |Feature status=` |Feature version=Firefox 9 |Feature health=OK |Feature status note=Soliciting feedback. }}
Team
| Product manager | Justin Scott |
| Directly Responsible Individual | Justin Scott |
| Lead engineer | Dave Townsend, Wil Clouser |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=Justin Scott
|Feature feature manager=Justin Scott |Feature lead engineer=Dave Townsend, Wil Clouser |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/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.
Stage 1: Definition
1. Feature overview
The vast majority of add-ons work from one version of Firefox to 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 for use. For add-ons hosted on AMO, this is done automatically. However, 75% of add-ons in use are not hosted on AMO, and are therefore a major compatibility obstacle for our users. All of the compatibility effort put into each release is simply because Firefox still assumes add-ons will be incompatible between versions, when they usually aren't.
We should change Firefox's assumption to be that add-ons are compatible, with a few exceptions. Binary add-ons are never compatible between releases and are also the highest risk of negative side effects. Firefox should automatically enable low-risk (non-binary) add-ons in new versions of Firefox, and check AMO for additional compatibility information.
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.
2. Users & use cases
`
3. Dependencies
`
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
Firefox 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:
1. If the add-on is already marked as compatible with the new version, either in its included install manifest or via its updateURL update manifest, the add-on remains enabled.
2. If the add-on is not marked as compatible, Firefox will look at its install.rdf to see if the author has opted out of compatible by default and requested strict compatibility mode. If they have, the add-on is incompatible and should be disabled in the new version of Firefox.
3. Next, Firefox will look for binary components in the add-on. If binary components are found, the add-on is incompatible and should be disabled in the new version of Firefox.
4. 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 actually not compatible with the new version, or it may report that it is compatible with the new version. If there is no compatibility information returned for the particular version of the add-on with the particular version of Firefox, the fallback methods should be used.
Firefox will then inform the user, if necessary, about incompatible add-ons, or update to the new version and automatically enable the add-ons that would otherwise be incompatible.
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 needs to return compatibility information about add-ons, even non-hosted ones, in its GUID search API responses.
We'll need an admin tool where add-on GUIDs can be entered/selected and compatibility information with add-on versions and versions of Firefox can be saved.
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 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.
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
` {{#set: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 to 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 for use. For add-ons hosted on AMO, this is done automatically. However, 75% of add-ons in use are not hosted on AMO, and are therefore a major compatibility obstacle for our users. All of the compatibility effort put into each release is simply because Firefox still assumes add-ons will be incompatible between versions, when they usually aren't.
We should change Firefox's assumption to be that add-ons are compatible, with a few exceptions. Binary add-ons are never compatible between releases and are also the highest risk of negative side effects. Firefox should automatically enable low-risk (non-binary) add-ons in new versions of Firefox, and check AMO for additional compatibility information.
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=` |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=Firefox 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:
1. If the add-on is already marked as compatible with the new version, either in its included install manifest or via its updateURL update manifest, the add-on remains enabled.
2. If the add-on is not marked as compatible, Firefox will look at its install.rdf to see if the author has opted out of compatible by default and requested strict compatibility mode. If they have, the add-on is incompatible and should be disabled in the new version of Firefox.
3. Next, Firefox will look for binary components in the add-on. If binary components are found, the add-on is incompatible and should be disabled in the new version of Firefox.
4. 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 actually not compatible with the new version, or it may report that it is compatible with the new version. If there is no compatibility information returned for the particular version of the add-on with the particular version of Firefox, the fallback methods should be used.
Firefox will then inform the user, if necessary, about incompatible add-ons, or update to the new version and automatically enable the add-ons that would otherwise be incompatible.
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 needs to return compatibility information about add-ons, even non-hosted ones, in its GUID search API responses.
We'll need an admin tool where add-on GUIDs can be entered/selected and compatibility information with add-on versions and versions of Firefox can be saved.
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 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. |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Add-ons |
| Secondary roadmap | Firefox Desktop |
| Feature list | Desktop |
| Project | ` |
| Engineering team | Desktop front-end |
{{#set:Feature priority=Unprioritized
|Feature rank=999 |Feature theme=` |Feature roadmap=Add-ons |Feature secondary roadmap=Firefox Desktop |Feature list=Desktop |Feature project=` |Feature engineering team=Desktop front-end }}
Team status notes
| status | notes | |
| Products | ` | From the desktop side, we would like this to be prioritized as a P1 and part of achieving "silent update". |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=From the desktop side, we would like this to be prioritized as a P1 and part of achieving "silent update". |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}