Building extensible software is a tricky business. On one hand, you want your platform to be as customisable as possible, while on the other you want the flexibility to update APIs to make them faster, more secure and feature-rich. These aims aren’t always compatible, as we’re now discovering with Mozilla and the fundamental changes it’s making to Firefox’s add-on infrastructure.
As the company’s Kev Needham outlines in a blog post on Mozilla’s Add-ons Blog, there are some significant incoming changes being made to the browser to “take advantage of new technologies” and better defend users against malicious software. Unfortunately, the upgrades are going to come at a cost — the depreciation of some core libraries a great deal of add-ons rely on.
First, the good news. Firefox plans to adopt the WebExtensions API, which according to Needham, will make it easier for add-on developers to port extensions between browsers. If you’ve ever tried coding one, you’ll know each browser has its own way of doing things. Standardisation in this regard would be a nice thing.
Next up is moving to a multi-process design — a project codenamed “Electrolysis”. Like Chrome, the idea is each tab is sandboxed, preventing a problem in one affecting the other — including malware.
Now for the not-so-great news. Such a shift from single to multi-process will break a lot of add-ons. Not only that, Mozilla wants to retire XPCOM and XUL, the two technologies that make Firefox add-ons as flexible and powerful as they are (compared to competitors). The reason for kicking them to the curb is that the “tight coupling” seriously affects Mozilla’s ability to improve 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 … Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL.
The post goes on to mention that the changes will be made over the course of the next 12-18 months, introduced bit-by-bit over Firefox versions 41, 42 and 43. So add-on developers have plenty of time to prepare, however, the end result is a less customisable, but more secure, Firefox.