Mozilla today announced major changes are coming to how Firefox add-ons are built. While this is mainly aimed at add-on developers, the end results will trickle down to Firefox users over the next few months and years.
Back in the day when Firefox was battling Internet Explorer, add-ons were one of the key differentiators that made Mozilla’s browser stand out. They are not as big of a deal today as most browsers support a similar feature, like Chrome with its extensions, but they are still supported by a massive developer community.
That group of add-on makers has four announcements to digest today:
Add-ons will soon be built with the WebExtensions API, which is largely compatible with the model used by Chrome and Opera and should make it easier to develop extensions across multiple browsers.
Add-ons will have to support multi-process Firefox, which is coming soon as part of the Electrolysis project.
Add-ons will have to be validated and signed by Mozilla, in the name of security and performance, starting in Firefox 41, which is slated for a September 22 release.
Add-ons built with XPCOM and XUL will be deprecated within 12 to 18 months from now.
From VentureBeat
Your customers are hitting your platform from several different devices — are you prepared? Free webinar on the omnichannel marketing strategy.
Only the first of these announcements is completely new. We’ve heard about the other three for a while now, most recently last month when Mozilla announced its plans for Firefox. Still, today there are a lot more details on how exactly add-ons are being revamped.
Mozilla admits these changes will “require redevelopment of a number of existing add-ons.” To support the changes, the company is expanding the team of engineers, reviewers, and evangelists who work on add-ons to improve and finalize the WebExtensions API and help unsupported add-ons make the transition.
WebExtensions API
Mozilla says add-on developers want better documented and easier to use APIs, and many of them also maintain a Chrome, Safari, or Opera extension with similar functionality. The goal with WebExtensions is to make add-on development 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 WebExtensions API is compatible with Blink, the rendering engine used by Chrome and Opera. Mozilla is aiming for extension code written for Chrome and Opera to be able to run in Firefox “a minimal number of changes.” The company also mentions Microsoft Edge, which is slated to support extensions in the near future as well.
The JavaScript-centric API supports multi-process browsers by default and mitigates the risk of misbehaving add-ons and malware. WebExtensions will be signed and discoverable through addons.mozilla.org or through the developer’s website.
If you’re a developer, you’ll want to check out the preview release of WebExtensions, available in Firefox 42 Developer Edition. Information on how to start testing WebExtensions is available in the Mozilla wiki.
Multi-process support
As part of the Electrolysis project, Mozilla has been building multi-process Firefox support for many months. In fact, work to make the frontend and add-ons support multiple processes began in early 2013. Most recently, Firefox Nightly gained multi-process support in November 2014.
Mozilla believes using a separate rendering process lays the foundation for significant performance and security improvements in Firefox. That said, it also breaks some add-ons, especially those that modify content. The company plans to address this with the following mitigations:
WebExtensions are fully compatible with Electrolysis. As the API matures and Electrolysis is enabled by default, this will be the way to port or develop extensions for Firefox.
Add-ons based on the Jetpack SDK will work well as long as they don’t require(‘chrome’) or some of the low-level APIs to touch objects in the content process.
Add-ons that haven’t been upgraded to work with Electrolysis will run in a special compatibility environment that resembles single-process Firefox as much as possible. If an add-on touches content, the access will happen via cross-process object wrappers (CPOWs). However, CPOWs are much slower than the equivalent DOM operations in single-process Firefox, and can affect the user experience negatively. Also, some accesses aren’t supported by the compatibility layer and will throw exceptions.
The final release schedule for Electrolysis is still in the air. That said, Mozilla is asking developers to update their add-ons to meet the current release plan:
August 11: Firefox 42 arrives in the Developer Edition channel.
September 22: Firefox 42 arrives in the Beta channel. Beta users will be able to opt-in to try Electrolysis.
November 3: Firefox 43 arrives in the Beta channel. Electrolysis will be enabled by default for beta users. Electrolysis-incompatible add-ons that cause major performance and/or stability problems will be blocklisted.
December 15: Firefox 43 arrives in the Release channel. Electrolysis will be enabled by default.
Six to 12 months after enabling Electrolysis on the Release channel: CPOWs and compatibility shims will be deprecated.
Developers can check out a list of popular add-ons for compatibility testing at arewee10syet.com.
Mandatory signing
When Mozilla released Firefox 40 last week the company kicked off its plan to require that all Firefox add-ons are certified, regardless of where they are hosted. Digital signing will be done through addons.mozilla.org.
In Firefox 40, the browser warns the user about unsigned add-ons, but doesn’t yet disable them. In Firefox 41, extensions that haven’t been certified will be disabled, but the browser will offer a preference that allows signature enforcement to be disabled (xpinstall.signatures.required in about:config). In Firefox 42, both the beta and release versions of Firefox will not allow unsigned extensions to be installed, and there will be no way to override this. The Nightly and Developer Editions of Firefox 42 and above will retain the preference to disable signing enforcement, allowing the development and/or use of unsigned add-ons in those versions.
Mozilla says this is being done in the name of security:
We currently use a blocklisting mechanism to defend against malicious add-ons, but additional measures are needed to better protect our users as some add-on developers have adapted to work around blocklisting. Blocklisting is also reactive: users can be harmed by dangerous add-ons that are installed until they are identified and blocked.
At the same time, with mandatory signing and by moving to WebExtensions, Mozilla hopes to speed up the review process for add-ons. The company says it is “easier to develop a correct WebExtension, and the permissions system makes it easier to recognize malicious add-ons.”
The company hopes to increase automation of the review process so that the wait time for reviews of new WebExtensions listed on addons.mozilla.org can be reduced to five days, and that the wait time for updates to existing WebExtensions can be reduced to one to two days.
Deprecating XUL, XBL, and XPCOM
Again, we learned last month that Mozilla wants to drop XUL and XBL. Both markup languages are used to build Firefox and its features, but the company considers them outdated and wants add-ons to be built with the same technologies that developers use to build Web content.
This would eliminate the need to support XUL and XBL in Gecko, Firefox’s rendering engine, and would make it easier for anyone to contribute to the Firefox project (as learning XUL and XBL would no longer be required). XUL and XBL are essentially Mozilla-specific languages, and thus obviously much less widely known than Web technologies. Mozilla now says it also wants to ditch XPCOM, its cross-platform component model.
Here is the company’s reasoning:
A permissive add-on model means that we have limited flexibility in changing the foundations of Firefox. The add-on breakage caused by Electrolysis is an important example of this problem. Technologies like CPOWs help us to work around add-on problems; however, CPOWs have been a huge investment in effort and they are still slow and somewhat unreliable.
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.
The tight coupling between the browser and its add-ons also creates shorter-term problems for Firefox development. It’s not uncommon for Firefox development to be delayed because of broken add-ons. In the most extreme cases, changes to the formatting of a method in Firefox can trigger problems caused by add-ons that modify our code via regular expressions. Add-ons can also cause Firefox to crash when they use APIs in unexpected ways.
Aside from plans to deprecate these 12 to 18 months from now, Mozilla doesn’t yet have a specific timeline to share.
Necessary changes
Mozilla says its add-on ecosystem has evolved through incremental, organic growth over the years, but because of upcoming modernizations coming to Firefox, all of the above changes are necessary. The company wants add-ons to take advantage of new technologies, to be more secure, and to take less time to review.
While that sounds great and all, the reality is that this will be a very painful time for Firefox add-on developers. The potential benefits are great, but how the add-on developer community will react is a big question mark.
More information:
Powered by VBProfiles