Features/Add-ons/Add-ons Default to Compatible: Difference between revisions

Latest revision as of 21:08, 10 February 2012

Please use "Edit with form" above to edit this page.

Status

Silent Update: Add-ons Default to Compatible
Stage	Shipped
Status	Complete
Release target	Firefox 10
Health	OK
Status note	Changes landed and enabled on Fx10.

{{#set:Feature name=Silent Update: Add-ons Default to Compatible

|Feature stage=Shipped |Feature status=Complete |Feature version=Firefox 10 |Feature health=OK |Feature status note=Changes landed and enabled on Fx10. }}

Team

Product manager	Justin Scott
Directly Responsible Individual	Lawrence Mandel
Lead engineer	Blair McBride (client), Wil Clouser (AMO)
Security lead	`
Privacy lead	`
Localization lead	Axel Hecht
Accessibility lead	`
QA lead	Virgil Dicu
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	Dave Townsend

{{#set:Feature product manager=Justin Scott

|Feature feature manager=Lawrence Mandel |Feature lead engineer=Blair McBride (client), Wil Clouser (AMO) |Feature security lead=` |Feature privacy lead=` |Feature localization lead=Axel Hecht |Feature accessibility lead=` |Feature qa lead=Virgil Dicu |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=Dave Townsend }}

Open issues/risks

What mitigation is needed to detect and fix negative effects of truly incompatible add-ons?

See Detection and Mitigation for the current plan.

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

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.

3. Dependencies

The operational side of this feature, how to detect and handle incompatibility cases, is detailed on the Detection and Mitigation page.

4. Requirements

`

Non-goals

This plan is not trying to solve the issue of binary compatibility between releases.

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 at the compatibility info, to see if the specified minVersion is greater than the running appl;icatin's version. If it is, then Firefox will assume the addon is not backwards compatible, and mark it as incompatible.

4. 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.

5. 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 compatibility is unchanged from steps 1-3.

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 help ensure correct behaviour. At minimum this test should verify that no JS exceptions occur during startup and no XML parsing errors occur during startup. 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 (see also Support/Firefox_Features/Clean_up_user_profile).

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

Add-ons Manager bug: bug 692664 (Dependency tree)
Remaining bugs that need fixed before release
- bug 706387 Send the compatibility mode when using AMO Search API
Future work:
- bug 570033 Consider exposing add-on compatibility checking status of the browser.
- bug 695581 Self-test to ensure compatible-by-default addons are working correctly

AMO bug: bug 691834 (Dependency tree)
In order to land in 10 requires
- ~~bug 698355~~ in order to update addons that are compatible-by-default
- ~~bug 698358~~ in order to update the small sub-section of addons that opt-in to strict compatibility (none now, hopefully very few in the future, but something we need to fully support)
- bug 706385 to make AMO search within the Add-ons Manager return all compatible results

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=What mitigation is needed to detect and fix negative effects of truly incompatible add-ons?

See Detection and Mitigation for the current plan. |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=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 dependencies=The operational side of this feature, how to detect and handle incompatibility cases, is detailed on the Detection and Mitigation page. |Feature requirements=` |Feature non-goals=This plan is not trying to solve the issue of binary compatibility between releases. |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: