Features/Jetpack/Out-of-Process Addons

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Users sometimes complain that Firefox is slow. In a significant number of cases, investigators have found that the problem is caused by one or more addons performing poorly. Addon performance problems impact Firefox performance, and they are difficult for users and developers to discover, because there are no tools for measuring addon resource consumption.

Loading and executing addons in separate processes would make Firefox resilient against addon performance problems and make it easier for users and developers to identify and resolve such problems using process inspection tools.

As a side-effect, the feature may improve the addon security model, to the degree that an addon vulnerability is more difficult for malicious content to exploit when the addon is executed in a separate process.

With the Add-on SDK, we want to make Add-ons built with the SDK to automatically work with the new electrolysis multi-process automatically. We want the end user (developer) to never have to think about what e10s is or how to make the add-on use it, we just want it to use it.

2. Users & use cases

The target audience is addon developers. The use case is simply that an add-on developer using the Add-on SDK (either directly or via the Add-on Builder) will build their add-on and it will automatically run in a separate process when installed and running in Firefox. The developer should never have to worry about making the add-on take advantage of e10s at all.

3. Dependencies

The feature depends on platform support for loading and executing add-ons in separate processes.

It may also depend on decisions we make about providing a more web-page-like environment to addons.

4. Requirements

The feature must load an addon built using the SDK in a separate process by default. It must support the existing high-level APIs as provided by the first stable release of the SDK (Add-on SDK 1.0), which use content scripts to give addons access to content and abstract away the details of Firefox chrome modification. It must also support similar high-level APIs that land in subsequent stable releases.

It may support simpler alternatives to the existing high-level APIs, such as cross-process proxies that provide access to DOM objects in the addon process.

It may allow addon developers to disable the feature to accommodate addons that use second- and third-party APIs that are not OOP-compatible.

Non-goals

The feature should not attempt to support using the SDK's APIs in core Firefox development. It should not attempt to address some aspect of the SDK's security model. These goals are worthy but best addressed by orthogonal or subsequent efforts.

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

Phase One

Implement and land platform support for creating suitable processes and loading addon code in them. Modify the SDK's loader to load addons in separate processes. Modify the SDK's high-level API implementations (and, by extension, its low-level ones) to function correctly when the APIs are accessed from a separate process.

http://etherpad.mozilla.org:9000/cyARtcloJu

Phase Two

Investigate simpler alternatives to the existing high-level APIs, such as cross-process proxies that provide access to DOM objects in the addon process.

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

While this work will provide some necessary functionality to the SDK support for mobile work, we have determined that it is not a blocker to getting mobile support working in a minimal functional way.

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes