Mozilla’s self-destruct course continues: major add-on compatibility changes announced

Mozilla announced major upcoming changes to Firefox add-ons on the official Add-ons Blog today. These changes affect add-on developers and Firefox users alike, and will have a major effect on add-on compatibility and permissions.

The four major changes that Mozilla mentions explicitly in the announcement are add-on validation and signing, the multi-process architecture Electrolysis, the implementation of a new extension API WebExtensions, and the deprecation of XPCOM and XUL based add-ons.

WebExtensions

We would like add-on development to be more like Web development: the same code should run in multiple browsers according to behavior set by standards, with comprehensive documentation available from multiple vendors.

The new API will make it easier to port add-ons from one browser to another. In addition, it will improve reviews significantly and cut down on the time it takes to review add-ons before they are published on Mozilla AMO.

The API itself shares many similarities with Google's Blink API so that it should be easier for developers to port Chrome extensions to Firefox and Firefox add-ons to Chrome.

Add-ons that use WebExtensions are automatically compatible with Firefox Electrolysis and more robust when it comes to internal code changes in the browser.

A preview release of WebExtensions is available in Firefox 42.

Multi-process Firefox / Electrolysis (e10s)

The release of Electrolysis will have a huge impact on add-ons in the Firefox browser. Interested users can check out the Are we e10s website to find out if add-ons that they are using are compatible with e10s yet.

There they may also test add-ons and report their findings to support Mozilla and Firefox development.

Mozilla has yet to announce a final release date for the first phase of Electrolysis. The feature is activated by default in Developer and Nightly versions of the web browser.

The organization plans to offer Electrolysis as an opt-in when the Beta channel is updated to Firefox 42 on September 22.

Mozilla may enable Electrolysis by default when the beta channel hits version 43, and that is also the earliest version in which the stable channel of the browser may get it.

Add-ons that are not compatible with Electrolysis when it is enabled by default in Firefox Beta will be blocked at that point if they cause major performance or stability problems.

A special compatibility environment has been created for add-ons that are not compatible in which they may run. The environment is much slower though and will only be made available for a period of six to twelve months before it is shut down again.

Add-on Signing

Nothing has change din regards to add-on signing. The idea behind the signing of add-ons is to improve the protection against malicious and harmful add-ons in the browser.

Firefox Stable and Beta versions -- starting with Firefox 42 -- will only accept signed add-ons during installation and block the installation of unsigned add-ons at this point.

Developer and Nightly versions of Firefox will block those as well by default, but they do support an override to install unsigned extensions.

To get an add-on signed, developers need to submit it to Mozilla's Add-on repository. There it is reviewed and signed when accepted.

Deprecation of XUL, XPCOM and the permissive add-on model

The deprecation will take place within 12 to 18 months, and Mozilla plans to continue to support SDK add-ons as long as they don't use require ('chrome') or low-level APIs that provide access to XUL elements.

The add-on model that XUL and XPCOM provide give add-ons full access to Firefox's internal implementation.

The tight interaction between browser and add-ons cause short and long term problems. Mozilla mentions the release of Electrolysis and the breaking of add-ons as an example.

The organization plans to extend the WebExtension API to support "as much of the functionality needed by the most popular Firefox extensions as possible".

Outlook and closing words

The changes have wide reaching consequences for Firefox's add-on landscape, users and add-on developers.

The permissive add-on model is what sets Firefox apart from other browsers. It led to impressive highly useful extensions such as NoScript, Greasemonkey, Down Them All, Tab Mix Plus, or Classic Theme Restorer, all of which don't exist on Chrome or any of the other browser's out there.

The deprecation will break lots of extensions and while some may be saved by the addition of new methods and options to the API, others that are not as popular will stop working altogether.

Nils Maier, developer of Down Them All puts it this way:

The flexibility of what XUL-based add-ons can do IS the major selling point of the Firefox add-ons ecosystem and therefore IS one of the last remaining selling points of Firefox itself that isn’t purely ideological. In comparison, the APIs that Chrome and competitors offer, that the Firefox Jetpack/ Add-on SDK offers, are just… toys.

Now You: Is Mozilla on self-destruct course? What's your take on this?