Status: draft

This is a draft, looking for feedback.

Proposal

WebExtensions moves into a system (or go faster) add-on.

Rationale

It's important to get WebExtensions out to developers, have them be used and be useful. There is a lead time between when we land the add-on API to when a developer can get around to implmenting an add-on based on it. As an example, anything landing past 2016-08-01, will not go to release until 2017.

There's a good reason for that flow for many parts of Firefox, but it doesn't mean they need to apply to all parts of Firefox. In order to get WebExtensions out there as soon as possible and assist people with the upcoming deprecations, we need to get WebExtensions useful and relevant as soon as possible.

Details

Example timeline

This is an example timeline, where in Firefox takes 6 weeks.

         +-------------------------------------+
Firefox  |Beta               |Stable           |
         +-------------------------------------+

         +--------------------
Web Ext  |2.0      |2.1      |
         +-------------------------------------+
         |3.0      |3.1      |2.0     |2.1     |
         +-------------------------------------+

In this example, development would be in a three week cycle. Each Beta and Stable would get the newest version. But we could ship minor releases every three weeks. It implies that WebExtensions would mostly skip Aurora and we would cut a release of WebExtensions and land it on Beta.

Those schedules are arbitrary but used as an example. It could be 3 weeks or 6 weeks.

Note: this was updated from the original which suggested 4 weeks, this one fits much more nicely.

native.js

There's been a proposal for running experiemental code in an add-on and shipping that out to users. This is very similar to this proposal and having a whole pile of API's living inside an add-on which users will install. https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457

If the stable core of WebExtensions is a system add-on, then you can install the native.js add-on over the top of the system add-on and it will override it. That means that each time we release a new stable core of WebExtensions, we'll also need to bump the native.js add-on and bundle all of stable inside native.js. It means that developers can install native.js to get all the experimental code.

This means we'll essentially be responsible for two add-ons, although only one of them could be active at a time.

Project lifecycles

Projects go through various lifecycles, they have an initial phase where they need to get as many users as possible. That oftern means quicker cycles, faster feature implementations and faster bug fixes. Once a product has reached a level of maturity and stability it will move slower.

For comparison the SDK went through a similar life cycle. It started out as a library that was packaged into each add-on and then later moved into mozilla-central. The SDK team never had system add-ons available to them.

The harder bits

Release cycles

Undefined at this point, but this needs to be a balance between risk and desire to push. The risk for add-ons causing breakages amongst other add-ons is low right now, but will increase as the add-on community builds out more add-ons. See early point about project lifecycles.

Testing

Currently this is a bit unknown for system add-ons. Ideally we want to be able to run our tests independently of mozilla-central, but be able to utilize the existing Firefox test infrastructure and test each release against all the versions of Firefox. Hello does this by pushing the code from github back into mozilla-central onto the fxteam branch and running the tests there.

Dependencies

There will be changes that cannot be done completely in the add-on. Some recent examples are webNavigation and webRequest where the underlying platform code need to be changed. This will require us to figure out in advance what requires platform changes and what does not and prioritize accordingly. Currently we are changing APIs to expose features the same as Chrome. This might not happen in the future once parity is reached and we are working on Firefox features.

Stabilizing

At some point in the future we can move this code back into the tree once we've reached a stable point. It doesn't mean we are on this train forever.

Reloading

When the system add-on gets installed and updates the APIs, we might need to reload all the add-ons. This is likely a similar problem for native.js

Addon Dependencies

Currently WebExtensions follow the existing Add-on dependency of specifying the version of Firefox. How that might work with system add-ons is something we'd need to explore.