Features/Jetpack/SDK Support for Firefox for Mobile Addons

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Firefox for Mobile (FFM) is a high priority for the Mozilla project, we expect it to attract a significant number of users, and we think FFM users are just as interested in customizing their browsing experience using addons as Firefox for Desktop (FFD) users.

FFM addons also support the [Mozilla Manifesto] principle that individuals "have the ability to shape their own experiences on the Internet."

And FFM addons help support the minimalist design philosophy of Firefox by allowing developers to build and users to use browser features that aren't part of the core product.

Thus FFM addons are as important as FFD addons. So it is just as important for the new addon platform provided by the SDK to support building addons for FFM.

Ideally, addons built using the SDK's high-level APIs should work on both FFD and FFM by default without requiring addon developers to specifically target mobile devices, f.e. high-level APIs that enable addons to introduce chrome elements should adapt those elements to the FFM and FFD interfaces.

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 use the SDK to create and add-on with either Desktop or Mobile in mind, and that add-on works in either platform with no extra effort or thought from the developer. In addition, if the developer wants their add-on to only work on FFM or FFD they should have the ability to toggle a flag to make it singular to that platform.

3. Dependencies

The feature may depend on landing support for specific interface elements in the FFM interface.

While there are elements to having support for out-of-process addons that will be necessary in the long run. We have determined that having e10s support is not a blocker to getting minimal support for mobile addons working.

4. Requirements

The feature must load an addon built using the SDK in both FFD and FFM. It should make addons that use only the high-level APIs provided by the SDK work by default on both FFD and FFM, although it may require addons to provide browser-specific code if it is not possible to make all APIs "just work" in both browsers.

It must enable an addon to determine which browser the addon is loaded in.

It may provide additional API features that are specific to mobile devices.

We must also continue the work that has already begun to reduce the footprint of an add-on built with jetpack.

Non-goals

`

Stage 2: Design

5. Functional specification

Phase One

Make it possible to load a simple addon that uses no high-level APIs in FFM.

Phase Two

Identify and resolve test failures in high-level APIs (and their low-level dependencies) one-by-one until all SDK tests pass when run against FFM.

Phase Three

Design and implement optimal FFM interface affordances for SDK APIs like Widget and Panel that modify Firefox chrome.

Phase Four

Design and implement additional API features for capabilities that are specific to mobile devices.

6. User experience design

Phase One

Coordinate with the UX team and Jetpack developers to map out the interface elements that are exposed in the APIs to FFM. This stage is critical in making add-ons usable and worth the effort.

Phase Two Implement the mappings.

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

`

Feature details

Team status notes