Deprecating XUL for WebExtensions

Mozilla first unveiled plans to revamp the development framework offered to extension authors in August, announcing that it would deprecate XUL and XPCOM in favor of an API based on JavaScript. That API, called WebExtensions, is now available to developers in the Firefox Nightly channel. The stable release is scheduled to arrive in mid-2016, and add-ons using the API should also be usable as extensions for the Chrome and Opera browsers.

XUL is the XML-based user-interface markup language used to define windows, menus, interface widgets, and other components in Firefox, Thunderbird, and a few other Mozilla projects. XPCOM is the corresponding component model, providing access to the various libraries that make up the application (networking, security, rendering engine, etc.). Both are well over a decade old and, while it could be argued that they have served their purposes well, they are integral enough to the structure of Firefox that they make it difficult to maintain a clear separation between the browser internals and third-party add-ons.

That has serious security implications, of course, and it also makes browser extensions rather brittle—susceptible to breakage when there are minor changes to the browser code itself. Meanwhile, Google's Chrome/Chromium (and the Opera browser, which also uses Chrome's Blink engine) have both found success attracting extension developers with the JavaScript-based Chrome extension APIs. By mirroring those APIs where possible, Mozilla believes it can attract new extension developers as well as enable many Chrome extensions to work in Firefox with a minimal amount of porting effort.

WebExtensions is Mozilla's name for the new API. It is worth noting that Mozilla terminology uses "API" in the singular, while Chrome's refers to same set of interfaces as APIs, plural. But this is purely semantics, just like how Mozilla refers to extensions, plugins, and themes, collectively, as "add-ons," while Chrome calls everything "extensions." There are more than 60 APIs defined for Chrome's extensions, with more constantly under development. They include everything from hooks to build user-interface elements to security features to the manipulation of page contents. Mozilla has set up a feature-tracking page for its implementation at AreWeWebExtensionsYet.com that lists the completion status for each API and links to open bugs and relevant documentation.

A WebExtension consists of JavaScript files bundled together with a JSON manifest file and any necessary resource files. WebExtensions can run background-process scripts as well as user-visible scripts (such as those that add to the browser interface or modify page content). WebExtensions will be subjected to the same security tests and signing rules imposed on extensions using the existing APIs. They will also retain the .xpi file extension, despite the internal differences with current add-ons. There are a few example extensions available as well.

Currently, the plan is on track for Firefox 45 (which is the series currently in the Nightly channel and which will become the stable Firefox release in March 2016) to fully support the contextMenus, browserAction, pageAction, and alarms APIs. The browserAction API allows an extension to place a button or icon on the toolbar; pageAction allows an extension to place one in the location bar. Like the name implies, contextMenus lets extensions add items to the right-click context menu, while alarms lets extensions schedule tasks. It is a rather small set of features; the plan announcement also noted that there should be "a bunch of partially supported APIs" available as well, including those used to access bookmarks, cookies, storage, and outgoing HTTP requests.

Ideally, the full set of WebExtensions APIs will be available as an experimental feature with the release of Firefox 47 (slated for release at the end of May 2016), and as a stable feature in Firefox 48 (July 2016). That said, even though the advertised goal of the project is to offer an API that closely mirrors that used by the Blink-based browsers, it appears that there will always be some differences.

The Mozilla wiki lists the interfaces that differ from those in the Chrome APIs. In some cases, the likelihood is that Mozilla will never implement the full Chrome API because it is bound too tightly to Google services. For example, in Chrome, the storage API (which is on the list to be partially supported for Firefox 45) supports not only the W3C localStorage standard, but Chrome's built-in cloud synchronization service and an enterprise "managed storage" policy. The Firefox implementation supports only localStorage.

There are other APIs where Firefox and Chrome will vary due to higher-level behavioral or policy differences. For example, Chrome provides separate cookie stores for each incognito tab, and the cookies API allows extensions to access those cookies as well as cookies from the standard browser store. Firefox's private-browsing mode, which is the nearest equivalent of incognito tabs, does not allow extensions to access the private-mode cookies at all. And there may still be additions to the WebExtensions API to provide access to Firefox-only features; the Mozilla wiki notes that Firefox supports special bookmarks like the "Recently Bookmarked" and "Recently Visited" folders that have no Chrome API equivalent.

In the future, though, Mozilla does seem to be aiming to maintain compatibility between the APIs where possible. No doubt that will be seen as a plus when marketing the API to Chrome or Opera extension developers. Even if some porting effort is required, it will be substantially lower than the costs of learning XUL and XPCOM.

Further out, Mozilla has several major changes lined up for Firefox, including the Servo rendering engine and the Electrolysis multi-process model. The August announcement of WebExtensions noted that reliance on XUL and XPCOM was an impediment to implementing both of those plans. The WebExtensions API implementation is explicitly designed to be Electrolysis-compatible.

Since they are being positioned to supplant XUL-based extensions entirely, WebExtensions will also be supported by Mozilla's Add-ons repository service. The developer documentation for the new API, which is still under construction, notes that currently WebExtensions can only be installed locally in Firefox Developer Edition or in Nightly builds. As the roll-out process continues, though, developers will be able to submit WebExtensions for testing and distribution through the Add-ons site. The announcement post that set out the timeline for WebExtensions' availability estimates that the Add-ons site will be ready for the new format by the time Firefox 44 is released—late January 2016.

If everything comes together as planned, then, extension developers can begin experimenting with the new API immediately, with an eye toward making their work available to early adopters in March. Migrating to an entirely new API can certainly seem like a daunting proposition, even if there is half a year between now and when the new API is scheduled to be declared stable. But much of that risk is mitigated by Mozilla's choice to adhere to the battle-tested interfaces used by Chrome and the other Blink-based browsers.

It is a gamble for Mozilla, one that may raise the ire of longstanding extension developers, but the move is well warranted given the long-term goals of work like Electrolysis and Servo. It is less clear whether adopting the same APIs used by Chrome will foster any cooperation on future extension development between Mozilla and the Chrome team, but at least Mozilla will have a seat at the table for such discussions—if it succeeds in bringing a sizeable number of extension developers along.