Mozilla today announced major changes to how Firefox will implement add-ons going forward. The most important of these is the adoption of a new extension API that will be largely compatible with the one currently in use by Blink-based browsers like Chrome and Opera. This so-called WebExtensions API will ensure that developers will only have to make a few small changes to their code for their add-on to run on Firefox.
“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,” Mozilla’s Kev Needham writes in today’s announcement.
Writing extensions for Firefox was always a bit more complex than writing something with the same functionality for Chrome. That’s partly due to Firefox’s use of technologies like XPCOM and XUL (for building user interfaces). These allowed the browser to be mostly written in JavaScript and ensured that extensions developers got access to a lot of Firefox’s underlying features, but also added complexity.
This “permissive model,” however, is now going away and add-ons that rely on XUL, XPCOM and the permissive add-on model these technologies enabled will be deprecated within 12 to 18 months.
It’s worth noting that these changes won’t apply to developers who use the newer Jetpack SDK to write their extensions (as long as they stay within the confines of Jetpack and don’t try to touch any low-level APIs).
Starting with Firefox 42, developers will also have to get their extensions reviewed and signed by Mozilla before they can be deployed. “Reviewing is a mostly manual, human process today, and moving an extension from the initial submission to passing a full review that meets our guidelines can be a time-consuming process that can take weeks or months,” Needham writes.
Mozilla, however, hopes that the move to the WebExtensions API will allow the organization to review add-ons significantly faster. Mozilla also has plans to automate more of the review process and bring the review time for extensions listed in its web store down to five days.
Mozilla is currently in the process of making another major change to Firefox, too. With the Electrolysis project, the organization is now finally separating the browser tabs and user interface into different processes so that a crashed tab doesn’t bring down the whole browser.
This feature is currently making its way through the Firefox developer channels and will be enabled by default in the first beta of Firefox 43. Some add-ons won’t work with Electrolysis out of the box, so Mozilla is urging developers to test their code to get ready for this switch.
Support for WebExtensions is already available in both the Firefox Nightly channels and the Developer Edition.
Overall, this marks a major change in how Firefox will treat add-ons. One thing Firefox always had going for it was that it had an extremely rich add-on ecosystem and that add-on developers were often able to do things in Firefox that weren’t possible in a browser like Chrome (including modifying the user interface).
It’ll be interesting to see how this move will impact the Firefox add-on ecosystem. For the most part, though, a unified extension ecosystem that allows developers to write their code once and then have it run on both Firefox and Chrome with just a few minor modifications will likely be a win for both developers and users.
The risk for Mozilla, however, is that it’s slowly doing away with many of the features that made its browser unique.
Featured Image: Johnathan Nightingale/Flickr UNDER A CC BY-SA 2.0 LICENSE
