Features/Add-ons/Add-ons Default to Compatible
Status
| Add-ons Default to Compatible | |
| Stage | Draft |
| Status | ` |
| Release target | Firefox 8 |
| Health | OK |
| Status note | Writing spec. |
{{#set:Feature name=Add-ons Default to Compatible
|Feature stage=Draft |Feature status=` |Feature version=Firefox 8 |Feature health=OK |Feature status note=Writing spec. }}
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 | Henrik Skupin |
| UX lead | Jennifer Boriss |
| Product marketing lead | Dan Horner |
| 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=Henrik Skupin |Feature ux lead=Jennifer Boriss |Feature product marketing lead=Dan Horner |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Firefox's switch to rapid releases has been stressful for add-on developers. Add-ons not hosted on AMO are especially pained, as they must update compatibility every 6 weeks without the benefit of automatic compatibility bumping.
Since the release of Firefox 4 and 5, we've learned that there are many more non-hosted add-ons than we previously thought, mostly those installed by other software. Whether users make use of these add-ons or not, seeing an incompatible add-on prevents many users from upgrading to new versions of Firefox.
More than 90% of add-ons are compatible from one version of Firefox to the next, and the ones that aren't usually have binary components that will need to be recompiled every release. If we change the default compatibility assumption, we can reduce the action needed to only the very small number of add-ons broken by the new release, rather than 100% of add-on developers.
We would move to a model where Firefox assumes add-ons are compatible unless they have binary components, the author has explicitly said to strictly observe stated compatibility, or it is reported to AMO as incompatible through the Add-on Compatibility Reporter.
It's possible and likely we will occasionally enable add-ons that don't actually work, but as we omit add-ons with binary components, this should not cause crashes and users will simply not have the functionality they expect, and will complain to the add-on author.
This process would not remove the need for AMO's automatic compatibility bumping, as it's still preferred for authors to be aware of changes in Firefox and learn about upcoming deprecations and other changes.
2. Users & use cases
`
3. Dependencies
`
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
When Firefox needs to determine an add-on's compatibility, it should do the following:
1. If the add-on is marked as compatible with the version, nothing needs to be done. 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 requested strict compatibility qualification. If they have, the add-on is incompatible and disabled.
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 treated as such (disabled).
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 about the add-on. If the add-on is not reported as incompatible from AMO, it should be enabled as compatible.
For AMO, this will involve returning information on compatibility reports received in response to metadata API requests, and support for returning information on non-hosted add-ons.
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=` |Feature overview=Firefox's switch to rapid releases has been stressful for add-on developers. Add-ons not hosted on AMO are especially pained, as they must update compatibility every 6 weeks without the benefit of automatic compatibility bumping.
Since the release of Firefox 4 and 5, we've learned that there are many more non-hosted add-ons than we previously thought, mostly those installed by other software. Whether users make use of these add-ons or not, seeing an incompatible add-on prevents many users from upgrading to new versions of Firefox.
More than 90% of add-ons are compatible from one version of Firefox to the next, and the ones that aren't usually have binary components that will need to be recompiled every release. If we change the default compatibility assumption, we can reduce the action needed to only the very small number of add-ons broken by the new release, rather than 100% of add-on developers.
We would move to a model where Firefox assumes add-ons are compatible unless they have binary components, the author has explicitly said to strictly observe stated compatibility, or it is reported to AMO as incompatible through the Add-on Compatibility Reporter.
It's possible and likely we will occasionally enable add-ons that don't actually work, but as we omit add-ons with binary components, this should not cause crashes and users will simply not have the functionality they expect, and will complain to the add-on author.
This process would not remove the need for AMO's automatic compatibility bumping, as it's still preferred for authors to be aware of changes in Firefox and learn about upcoming deprecations and other changes. |Feature users and use cases=` |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=When Firefox needs to determine an add-on's compatibility, it should do the following:
1. If the add-on is marked as compatible with the version, nothing needs to be done. 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 requested strict compatibility qualification. If they have, the add-on is incompatible and disabled.
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 treated as such (disabled).
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 about the add-on. If the add-on is not reported as incompatible from AMO, it should be enabled as compatible.
For AMO, this will involve returning information on compatibility reports received in response to metadata API requests, and support for returning information on non-hosted add-ons. |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 | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |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=` }}