Mozilla Add-ons Community Blog
Firefox Logo on blue background
Categories: developers webextensions

Advantages of WebExtensions for Developers

10 responses

First, a Little Backstory

Presently, Firefox supports two main kinds of add-ons. First were XUL or XPCOM add-ons, which interface directly with the browser’s internals. They are fabulously powerful, as powerful as the browser itself. However, with that power comes security risk and the likelihood that extensions will break as the browser changes.

The Add-on SDK was introduced to provide a stable abstraction API above browser internals to reduce extension compatibility issues between versions of Firefox and make it easier to review extensions for security. As the browser evolved, however, it became clear that we needed something even more robust to take us into the future.

WebExtensions is the new API for building add-ons in Firefox. It seeks to unify the extension APIs and architecture with those of other browsers in the name of interoperability and modern architecture.

The introduction of WebExtensions isn’t an arbitrary change—it stands to improve the stability and security of Firefox for users. It also has a number of advantages for developers.

Cross-Browser Interoperability

Potentially the most impactful aspect of WebExtensions is that it adopts the extension architecture used by browsers built on top of Chromium, notably Chrome and Opera. Mozilla is committed to implementing a large number of the individual APIs presently available to Chrome extensions. This means that it’s possible to have one codebase for an extension that will work in Firefox, Chrome, and Opera with a minimal amount of browser-specific code.

More than Chrome Parity

While our initial API priorities are focused on allowing Chrome extensions to interoperate with Firefox, we plan to competitively and actively expand the API capabilities of WebExtensions. While we anticipate the vast majority of Firefox Add-ons can be ported to WebExtensions, if you need access to browser components not presently exposed, the Add-on SDK is still available. If your add-on or one you use and love is doing something that is not possible with Chrome extensions or the Add-on SDK, please fill out this survey to help us prioritize new APIs.

Common Functionality is Easier

A large number of browser extensions take the form of content scripts, where Javascript is executed against certain (or in some cases all) web pages. WebExtensions optimizes for this case by allowing developers to reduce these types of extensions to 2 files: the script, and a manifest describing the extension and on which pages it should be injected.

Future-Proofing your Work

XPCOM/XUL add-ons are notoriously brittle, breaking whenever browser internals change. The Add-on SDK provides a more stable API surface, but has many synchronous APIs that cross between add-on contexts and web page contents. Mozilla is committed to moving Firefox to a multi-process architecture this year to increase security and stability (read more here), which will break many of these synchronous APIs. WebExtensions APIs are being implemented from the ground-up to be ready for a multi-process Firefox, using asynchronous message passing and event-driven interfaces to enable extensions to communicate with the browser and web pages.

More Secure Extensions

Because extensions built with the Add-on SDK can request XPCOM privileges, they could still introduce unintentional security and stability issues into Firefox. Even add-ons written by well-meaning developers can accidentally introduce vulnerabilities that could allow malicious code to execute with the full privileges of the browser. WebExtensions uses its manifest.json to mitigate this by requiring add-on authors to declare up front which permissions their code will need to operate. Unlike the Add-on SDK, WebExtensions does not allow arbitrary XUL/XPCOM access, so even insecure/vulnerable code is limited to its whitelisted subset of functionality. This vastly reduces the vulnerability surface of a WebExtension, leading to faster review times and a more stable browser.

The Path Forward

We know WebExtensions is a big change, and we’re committed to helping developers prepare and adapt as we roll it out. Initial support for WebExtensions is coming in Firefox 48, and add-ons built with WebExtensions can already be submitted to addons.mozilla.org. The time is now to start experimenting and porting your add-ons! Here are some links to help you get started:

  • If you’re an existing add-on author, check out this collection of resources on migrating your add-on to WebExtensions.
  • If you’re the author of a Chrome extension, we have a short guide on adding Firefox support to your existing codebase.
  • You can also check out this wiki to see more ways to participate in the evolution of WebExtensions.

10 comments on “Advantages of WebExtensions for Developers”

  1. Stefan wrote on

    The chrome.storage.local still doesn’t work in Firefox nightly 48.0a1 (2016-03-14) so can’t port the Turn Off the Lights Chrome extension. So there is lots of bugs in Firefox 48.

    1. Andy McKay wrote on

      From a content script as per https://bugzilla.mozilla.org/show_bug.cgi?id=1197346 or something else? If its something else and you have more details or a bug, that would help.

      1. Stefan wrote on

        yes the content.js script that doesn’t work here. Also why is there no button “Options” available in the about:debugging (to open our Turn Off the Lights extension settings page). Else the Firefox user can’t change the layer color or enable the Night Mode feature.

        1. Potch wrote on

          Stefan, the “options” button for extensions is located in the about:addons screen, not about:debugging- users will interact with your extension’s settings there.

          1. Stefan wrote on

            nope. See nothing on that page, and our old Turn Off the Lights XUL got the “preferences” button.

  2. Noitidart wrote on

    Advantages I had thought about, to convince me be to be pro WebExts:

    1) Rather then “Chrome Parity” I like to think of it as “Firefox Parity”. 🙂 I was going to make a image font face recognition addon but WebExt already handled it for me and uploaded to AMO, that’s super!

    2) So following point 1 above, many addons could be written by newcomer devs, freeing up the seasoned devs to focus on and maintain the more involved stuff.

    3) I really enjoy doing everything from ChromeWorkers without XPCOM and hope that stays, so personally I *hope* I never have to use the WebExt API. But I really welcome it and look forward to teaching it to the newcomers. It was super quick to learn. It’s hard to get newcomers involved with the current powerful system, as you try to teach them they can’t get it and lose interest. WebExts will really help in that area.

    4) Sometimes authors can’t maintain/support their addon anymore. Maybe the advanced addon devs might be able to extend their addon life by converting to WebExt so that newcomers can easily step in and take over. Some of my addons I treat like my babies so I wouldn’t hand it over, but the ones I don’t care as much for, if it’s possible to convert them, I definitely would rewrite to WebExt so it can be taken over and live on for the users that use it. I strongly believe addons should never *have to* die due no more technical support.

  3. Mister Lurker wrote on

    I’m really hoping that native.js will become a thing as well, so that XPCOM-like capabilities are still available. It sounds like a fantastic way to provide people with a way to still have advanced capabilities even knowing the risks and problems, while letting such addons have a chance to eventually become proper WebExtensions in their own right at a later date.

    I’ve also read interesting murmurs that WebExtensions may be a path to the future of theming capabilities in Firefox.. that sounds like a great idea too, at least in theory. It’s really nice to see Mozilla finally start addressing all of the concerns people have had over the years, even if it took until Electrolysis to get us here 🙂

  4. eddie wrote on

    There is this extension “Chrome store foxified” I have been using lately in aurora, many webextensions already work, this looks good

  5. Disappointed wrote on

    So, the first you mention here is Chromium based browsers.

    As you try so hard to offer as much as possible Chrome parity with your browser, i am switching over to the real Chrome.

    Destroying your strength for getting Chrome users on board which will never happen (at least not that much as you would love to see it).

    I used Firefox because it offered add-ons which no other browser had before. Now you took that away, here is my answer.

    I really hope that you are right in how much Chrome users will switch over to Firefox, because the amount of users you will lose with that and all other recent moves will be very big.

  6. Your Not Chrome wrote on

    Stop making Firefox a chrome clone. If I wanted chrome, I would have switched over to the damn thing.