This article is a technical comparison between the WebExtensions technology and "classic" extensions developed using direct XUL manipulation and direct access to XPCOM. It's intended to help orient people who maintain an add-on like this, and who are planning to port it to use WebExtension APIs.

Support for extensions using XUL/XPCOM or the Add-on SDK was removed in Firefox 57, released November 2017. As there is no supported version of Firefox enabling these technologies, this page will be removed by December 2020.

At a very basic level, XUL/XPCOM extensions are similar to extensions developed with WebExtensions. They both include:

manifest files defining metadata for the extension and some aspects of its behavior.

JavaScript code that gets access to a set of privileged JavaScript APIs and that stays loaded for as long as the extension itself is enabled.

the ability to add specific UI elements, such as buttons, to the browser.

Beyond that, though, the systems are very different. In particular:

Compared with XUL/XPCOM extensions, WebExtensions provide much more limited options for the extension's UI, and a much more limited set of privileged JavaScript APIs.

WebExtensions can only access web content by injecting separate scripts into web pages and communicating with them using a messaging API (note, though, that this is also true of XUL/XPCOM extensions that expect to work with multiprocess Firefox).

Manifest

XUL/XPCOM extensions have two manifest files:

the install.rdf contains metadata about the extension such as its name, icons, and so on

the chrome.manifest, that tells Firefox where it can find the components of the extension, including XUL overlays for the extension's interface, scripts for its behavior, and files containing localized strings.

WebExtensions have a single manifest file called manifest.json, that has a similar purpose. You use it to specify the extension's name, description, icons, and so on, as well as to specify any buttons it adds to Firefox and to list scripts it needs to run. To get an overview of the components of an extension developed using WebExtension APIs, and how they are specified in manifest.json, see "Anatomy of an extension".

Learn more

UI

XUL/XPCOM extensions can build their UI by directly manipulating the XUL used to specify the browser's own UI. They do this either using overlays or, in the case of bootstrapped/restartless extensions, using JavaScript to modify the XUL document. They can not only add any elements to the browser's UI, they can also modify or remove existing elements. They can also use APIs like CustomizableUI.jsm to build their UI.

Extensions built with WebExtension APIs don't get this kind of direct access. Instead, a combination of manifest.json keys and JavaScript APIs enable them to add a limited set of UI components to the browser. The available components are:

Privileged APIs

Both XUL/XPCOM extensions and extensions built with WebExtension APIs can contain scripts that stay loaded for as long as the extension itself is enabled, and that have access to a set of privileged APIs. However, XUL/XPCOM extensions get access to a much wider range of APIs.

The equivalent WebExtension scripts are called background scripts, and they get access to a much smaller set of high-level JavaScript APIs. To see all the privileged APIs available to background scripts, see the summary API page. Background scripts also get a window global, with all the DOM objects that are available in a normal web page.

There are vastly more APIs available to XUL/XPCOM extensions than are available to WebExtensions, and for many XUL/XPCOM APIs, there isn't a WebExtensions substitute. The table below lists every API in the popular Services.jsm module, describe what the equivalent WebExtensions API would be, if there is one.

You'll see that many APIs have no WebExtensions equivalent yet. However, we are intending to extend the WebExtension APIs to support the needs of add-on developers, so if you have ideas, we'd love to hear them. You can reach us on the dev-addons mailing list or #webextensions on IRC.

However, this is only possible in single-process Firefox. In multiprocess Firefox, web content and extension code run in different processes, so this direct access is no longer possible, and extensions which rely on it will break. Multiprocess Firefox is coming soon, and multiprocess compatibility will be a necessity.

WebExtensions are multiprocess-compatible by default: code that interacts with web content is factored into separate scripts called content scripts, that can communicate with the rest of the extension using a messaging API.

Learn more

Localization

In a XUL/XPCOM extension you handle localization by supplying DTD or properties for each supported language, and referring to them using locale statements inside the chrome.manifest. You can then include localized strings in UI elements or in code.

The general approach with WebExtensions is similar, but the details are all different. With WebExtensions you supply localized strings as a collection of JSON files, one for each locale.

WebExtensions don't have direct support for localizing strings appearing in HTML, so you have to do this yourself, using JavaScript to retrieve localized strings and to replace the HTML with the localized version.

Learn more

Settings

With WebExtensions you write an HTML file that presents the settings UI, which can include a script for persisting the settings for your extension. The script gets access to all the WebExtensions APIs, and it's generally expected that you should use the storage API to persist settings.

You then assign the HTML file's URL to the options_ui key in manifest.json. Your settings page then appears in the extension's entry in the Add-ons Manager. The options page can also be programmatically opened with an API call to browser.runtime.openOptionsPage.