Back in July, Mozilla disclosed plans to modernize its Firefox browser. Today, the organization made those plans more concrete, with a tentative timeline for introducing long-desired improvements such as the creation of a process per tab—and with it, a timeline for the end of support for traditional Firefox add-ons.

Mozilla has been working on a multi-process architecture for years. Called the Electrolysis project, work started in 2009, but was put on hold in 2011. Work was resumed in 2013, and it's finally getting near to a release. Over the next few months, Mozilla plans to flip the switch and enable Electrolysis in its various release channels. Tentatively, it'll be an opt-in feature in the beta channel from September 22nd, on-by-default in the beta channel from November 3rd, and on-by-default in the release channel from December 15th.

While this change is advantageous from a stability and security perspective, it's not without its cost. Current Firefox add-ins can intimately intertwine themselves with the inner workings of the browser using an API called XPCOM. With Electrolysis, that's not easily possible: the add-ins will operate in a separate process from the main Firefox shell, so can no longer wrap themselves around the browser's internals.

Mozilla has developed an interim solution called CPOWs ("cross process object wrappers"); these allow an XPCOM add-in running in one process to communicate with a separate process, as if the multiprocess architecture didn't exist. But CPOWs are slow and do not support every single scenario, so are not a solution for every single add-in, and not desirable long-term. Accordingly, Mozilla intends to phase out support CPOWs and the extensions that depend on them. The deprecation is scheduled for six months after Electrolysis lands in the stable Firefox build, so currently June 2016. Mozilla will turn off support for CPOWs entirely twelve months after Electrolysis' stable release.

After that, Mozilla will deprecate XPCOM add-ons entirely, along with the XUL graphical framework. This is currently expected to take about 18 months after the stable Electrolysis release.

To replace XPCOM add-ons, Mozilla is implementing an API called WebExtensions. This is the JavaScript and HTML-based extension API that Chrome and Opera already use, and Microsoft is adding a substantially compatible API to its new Edge browser. Once Microsoft and Mozilla have completed this work, developers should be able to write extensions that are largely compatible with Chrome, Firefox, and Edge.

Firefox will also continue to support add-ons built using the high-level APIs provided in its add-on SDK, provided that they do not use XUL.

Google requires Chrome extensions to be signed and installed via the Chrome store. Microsoft will do the same for Edge; its extensions will be digitally signed and distributed through the Windows store. Mozilla has similar plans for its new extensions. They will have to be digitally signed by Mozilla, and will generally be distributed through addons.mozilla.org. This digital signature mandate is also being implemented for current add-ons; after the November 3rd Firefox release (version 42), these will no longer work if they do not have a digital signature. Between now and then, unsigned extensions will be disabled by default, with an option to enable them. The Firefox Developer version will not have this signature requirement, enabling add-on developers to create their extensions in the first place.

This is set to be a painful transition for Mozilla. One of the features that made Firefox and won it so much geek cred in its early days was its rich extension model, allowing a wealth of customizations and extra functionality. Extensions were given fairly free and unfettered access to Firefox internals, including the HTML on the rendered page. This provided extension developers great power, but it also made Firefox brittle and hard to maintain. Mozilla needs to implement features such as Electrolysis to maintain parity with Firefox's competition—it's the only mainstream browser that lacks this kind of multiprocess model—and one of the things that made Electrolysis complicated to develop is the need to preserve support for XPCOM add-ons; a burden that neither Chrome nor Edge suffers.

Mozilla also wants the freedom to be able to use new technology such as the Servo rendering engine that is currently being developed using Mozilla's Rust programming language, and browser.html, a browser with a front-end developed using HTML, CSS, and JavaScript. Using these things will make Firefox easier to maintain, more secure, and perhaps even faster, but is fundamentally incompatible with current XPCOM and XUL extensions. They've served Firefox very well over the last fifteen or so years, but are now holding the browser back. For the good of the project as a whole, Mozilla has decided that it's time to make a transition.