14 DAY TRIAL // Mozilla has revealed its master plan regarding the add-ons ecosystem, which in recent months has been in turmoil due to a series of semi-explained changes.
First off, the company detailed the WebExtensions API, a new add-ons API which will be compatible with the extensions ecosystem used by Chrome, Opera, and Vivaldi.
"We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers," said Mozilla's Kev Needham.
What this means is that developers can develop a browser add-on that works out of the box and from the same codebase on multiple browsers, without having to manage 2, 3, or sometimes 4 different versions of the same extension.
With Chrome and Opera already running on this extensions system, with Vivaldi going through a testing phase, and with Microsoft seriously pondering the idea of adding support for Chrome extensions in Edge, this only leaves Safari and IE on the outside looking in.
While IE can be safely characterized as a dead end when it comes to future development, and with Safari devs providing some tools to convert Chrome extensions to Safari's ecosystem, we can safely say that developing a cross-browser add-on is about to get a whole lot simpler in the coming months.
While Mozilla devs are seeing this as a way for "their" extensions to work on other browsers, let's not forget this can be seen the other way as well. So if you're tired of those Chrome crashes, just check back with Firefox around version 42 and see if they work then, or download the Developer Edition 42.0a2 and check out the early implementation of the API.
Unfortunately, things will not be as simple as grabbing a link from the Chrome Web Store and installing the extension in Firefox. About the same time the WebExtensions API hits Firefox, Mozilla will also be announcing add-on signing as a mandatory process for all add-on installations, meaning that any (Chrome) extension to be installed in Firefox needs to be pre-approved by the Mozilla Add-Ons team beforehand.
So unless the extension's developer registers on the Mozilla Add-Ons portal and submits his extension for "signing" by Mozilla's automated system, users won't be able to install it, no matter how compatible it is with Firefox's new add-ons API.
The new API fits right in with Mozilla's other new features
"We are implementing a new, Blink-compatible API in Firefox called WebExtensions," said Mr. Needham. "This modern and JavaScript-centric API has a number of advantages, including supporting multi-process browsers by default and mitigating the risk of misbehaving add-ons and malware."
Yes! It all makes sense now. Mozilla is announcing mandatory add-on signing starting with Firefox 41 (opt-in) and 42 (obligatory), the Electrolysis project that adds multi-process support in Firefox Developer Edition (42.0a2), and now the WebExtensions API, also included with the same Firefox Developer Edition.
All these details, when put together, reveal that Firefox is moving into a new direction with its add-ons ecosystem, one in which extensions won't have full access to the core of Firefox, but one in which the Firefox core can benefit from more new features than before.
"Without a fundamental shift to the way Firefox add-ons work, we will be unable to use new technologies like Electrolysis, Servo or browser.html as part of Firefox," Mr. Needham also noted.
Unfortunately, this further means that the older add-ons model that revolved around XPCOM, XUL, and XBL will be deprecated, and all add-ons built on this older system will stop working in the next 12 to 18 months.
A premium on multi-process support
By switching to new technologies like Servo and Electrolysis, Mozilla is changing not only the way extensions interact with the browser and its content, but also how the browser works.
While multi-process support seems (and is) a good idea for anyone with a little bit of technical knowledge, it also means a complete overhaul of the entire browser's architecture.
This was the main reason why the WebExtensions API was developed, the older XUL add-on model being theoretically different from what Mozilla is trying to do with Servo.
While previously Firefox used one single OS process to mix browser code, extensions, and Web content, with its Electrolysis project, Mozilla is moving extensions into their own process.
Developing an extension using the WebExtensions API automatically makes it Electrolysis-compatible, and "as the API matures and Electrolysis is enabled by default, this will be the way to port or develop extensions for Firefox."