In case you didn’t hear about it, back in July, Mozilla revealed plans to modernise its Firefox browser and now they’ve released concrete plans on how to reach that road mark, such as the creation of a process per tab—and with it, the end of support for the traditional Firefox add-ons.
For those living under a rock, Mozilla has been working on multi-process architecture for quite some time now, since 2009 to be precise. Christened “Electrolysis”, the project was put on hold in 2011 but resumed in 2013 and is now finally in shape enough for release. Mozilla will therefore enable Electrolysis through its different release methods. It will be an opt-in feature for those using the beta version of Firefox from September 22nd onwards and will be a default option for those same beta testers from November 3rd onwards and on-by-default in the release channel from December 15th onwards.
While the upgrade is certainly advantageous in terms of stability and security, it’s not without its cost. A blog post on the official Mozilla blog goes on to describe the different changes but I’ll post a slightly dumbed down version here:
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 and as a result can no longer wrap themselves around the browser’s internals. What this means is that the add-ons won’t be able to communicate with each other over the multi-process architecture. A short term fix Mozilla implemented for this are CPOWs (Cross Process Object Wrappers). They essentially allow add-ons to communicate with a separate process, giving the illusion that the multi-process architecture doesn’t exist. However they are slow and not supported in every case, as a result they are only an interim solution, Mozilla plans to slowly phase out add-ons and CPOWs by June 2016.
18 months after the release of Electrolysis, support for XPCOM add-ons will end.
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 (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, allowing for your favourite extensions in other browsers to be readily available in Firefox as well.
Google requires Chrome extensions to be signed and installed via the Chrome 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. The Firefox Developer version will not have this signature requirement, enabling add-on developers to create their extensions in the first place.
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 transition will not be easy for Mozilla but I’m confident they’ll be able to weather it and with cross-process architecture, Firefox is going to be akin to a rabbit force fed energy drinks and sugar.
What do you think of Mozilla’s move to step away from add-ons and migrate to extensions? Do you think this will edge Firefox past Chrome in the browser wars? Let us know your thoughts in the comments below!
