Features/Jetpack/Traditional Addon Conversion to SDK Platform

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Most existing Firefox addons are built on the traditional addon platform. Their developers would benefit from the improvements in the new addon platform provided by the Add-on SDK, especially as Firefox/Gecko developers make changes to the browser (such as loading content in separate processes) that will break traditional addons.

2. Users & use cases

The target audience is addon developers who have built one or more addons using the traditional platform. For these developers, we will make sure that porting their existing add-ons over is as simple as possible, with tools and documentation to help them along in the process.

3. Dependencies

`

4. Requirements

The feature should make it possible to run, test, and package a traditional addon using the SDK's functionality. It should automatically convert addon metadata from the traditional format to the new one.

It should provide developers with documentation that explains which SDK features map to which features of the traditional platform and gives tips and tutorials for converting a traditional addon to an SDK-based addon.

It should identify kinds of chrome modification and suggest SDK APIs that developers can use to make similar kinds of modifications. It should identify XPCOM services and automatically convert them to CommonJS modules. It should identify code that runs at startup and automatically convert it to the addon's main code.

Non-goals

The feature should not attempt to support addons that ship binary components and should make that clear in the documentation. It should not attempt to provide tools and APIs for traditional addon development.

Stage 2: Design

5. Functional specification

Phase One

Make it possible to use the SDK to run and package a traditional addon from a directory containing the traditional addon's code in the filesystem layout associated with a traditional addon XPI. Automatically convert addon metadata from the traditional format to the new one. Make it possible to test the addon using the SDK's unit testing features.

Write documentation that explains which SDK features map to which features of the traditional platform and gives tips and tutorials for converting a traditional addon to an SDK-based addon.

Phase Two

Develop tools that identify kinds of chrome modification and suggest SDK APIs that developers can use to make similar kinds of modifications. Develop tools that identify XPCOM services and automatically convert them to CommonJS modules. Develop tools that identify code that runs at startup and automatically converts it to the addon's main code.

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

We have determined that with the release of our support for e10s, we will have to break our low-level APIs (not the commonly used high-level APIs). Because of this, it is best if we deliver any tools and messaging around this feature until after we have landed this breaking-change feature.

Feature details

Team status notes