Add-ons/2017
This page covers the 2017 planning process for the add-ons team. As we go through the planning process more details will be made here. It details the 2015 blog post and the 2017 plans.
Contents
- 1 Timeline
- 2 Other applications
- 3 Projects affected
- 4 Q+A
- 4.1 How will the plans affect themes?
- 4.2 What level of Chrome parity support be?
- 4.3 Will every extension be possible to port?
- 4.4 How do users port over to new WebExtension version of an add-on?
- 4.5 How do I port my extensions data?
- 4.6 What kind of uptake are we seeing in converting to WebExtensions?
- 4.7 Will documentation on MDN about writing add-ons using legacy technologies be removed?
- 4.8 Will add-ons continue to work on Firefox 52 ESR?
Timeline
Summary: by Firefox desktop 57 (due for release November 2017), only WebExtensions style extensions will be loaded into Firefox.
Firefox 51
All add-ons without multi-process compatible explicitly set to false will be enabled with e10s using shims where appropriate. Please note: this will depend upon how well this number of add-ons performs in Beta 51 testing.
Firefox 52
ESR and Windows XP release.
Firefox 53
AMO will no longer sign new SDK, XUL or XPCOM based extensions for Firefox Desktop and Android. Only new WebExtensions add-ons can be created for Firefox Desktop and Android. Existing SDK, XUL or XPCOM based add-ons can still be updated and signed. Thunderbird and Seamonkey extensions will be unaffected.
Firefox 57
Only the following add-on types will be loaded by Firefox in release:
- Signed WebExtensions.
- Signed bootstrapped system add-ons.
- Language packs.
- Dictionaries.
- OpenSearch plugins.
- Lightweight themes.
Other applications
Desktop
The majority of Chrome add-ons now work with Firefox Desktop and can be ported over to use Firefox. Between now and Firefox 57 we aim to complete the remaining APIs and differences that exist between Chrome and Firefox.
There are some known incompatibilities that we do not intend to implement such as:
- APIs that are very unpopular on Chrome
- APIs that are deprecated by Chrome
- APIs that don’t work without major modification to Firefox
Android
At this time the level of WebExtensions is not good enough to provide a reasonable timeline for Android support. Once Android has reached reasonable support, we’ll aim for a similar timeline for Android.
Thunderbird
At this time we are unsure what Thunderbird’s plans are with WebExtensions.
Projects affected
This is a brief summary of some of the projects affected. As the plans become better developed, we'll expand this out.
Release Engineering
Add-ons like Super Powers are used in the test suite.
Test Pilot
The main Test Pilot add-on is an SDK add-on. The experiments that exist (and are planned) are a mixture of SDK and WebExtensions.
Shield Add-ons
The Shield add-ons are SDK add-ons.
Developer Tools
The DevTools team manages several SDK add-ons, ADB Helper and Valence, that extend the tools.
Third party add-ons
Those not developed by a team within Mozilla.
Q+A
How will the plans affect themes?
Complete themes based on XUL will no longer be supported. A new 1330328 theming API is currently under construction that will provide something more powerful than existing lightweight themes without the downsides of XUL themes.
What level of Chrome parity support be?
We plan to have the majority of APIs and functionality available, but there are some parts of the API that will not be available. See this blog post for more.
Will every extension be possible to port?
No. WebExtensions has a specific API that allows certain things to be done, but not others. In some cases there will be no possible way to re-create the extension. In other cases the functionality might have to change.
How do users port over to new WebExtension version of an add-on?
When users update the add-on as long as the add-on id is the same, the WebExtension version will override the old version.
How do I port my extensions data?
The Embedded WebExtension approach lets you do a release of the add-on that contains a WebExtension. In that release you can port data over and follow it up with a release that is completely WebExtension based.
What kind of uptake are we seeing in converting to WebExtensions?
Some positive responses from developers who currently maintain two code bases, however challenges remain over add-ons that use XUL or other legacy technologies.
Will documentation on MDN about writing add-ons using legacy technologies be removed?
Yes, the focus will be on WebExtensions from now on and we’ll continue to point all pages over to WebExtensions.
Will add-ons continue to work on Firefox 52 ESR?
Yes, we’ll support add-ons on Firefox 52 as long as that release is supported.
