Categories: webextensions

WebExtensions in Firefox 56

Firefox 56 landed in Beta this week, so it’s time for another update on the WebExtensions transition. Documentation for the APIs discussed here can be found on MDN Web Docs.

API changes

The browsingData API can now remove cookies by host. The initial implementation of browsingData has landed for Android with support for the settings and removeCookies APIs.

The contextMenus API also has a few improvements. The text of the link is now included in the onClickData event and text selection is no longer limited to 150 characters. Optional permission requests can now also be triggered from context menus.

An alternative, more general namespace was added, called browser.menus. It supports the same API and all existing menu contexts, plus a new one that allows you to add items to the Tools menu. You can also provide different icons for your menu items. For example:

  id: "sort-tabs",
  title: "A-Z",
  contexts: ["tools_menu"],
  icons: {
   16: "icon-16-context-menu.png",

The windows API now has the ability to read and preface the title of the window object, by passing titlePreface to the window object. This allows extensions to label different windows so they’re easier to distinguish.

The API now requires user interaction to be called. This mirrors the Chrome API which also requires user interaction. You can now download a blob created in a background page.

The tabs API has new printing APIs. The tabs.print, tabs.printPreview and tabs.saveAsPDF (not on Mac OS X) methods will bring up the respective print dialogs for the page. The tabs.Tab object now includes the time the tab was lastAccessed.

The webRequests API can now monitor web socket connections (but not the messages)  by specifying ws:// or wss:// in the match pattern. Similarly the match patterns now support moz-extension URLs, however this only applies to the same extension. Importantly a HTTP 302 redirection to a moz-extension page will now work. For example, this was a common use case for extensions that integrated with OAuth.

The pageActions API can now be shown on a per tab basis on Android.

The privacy API gained two new APIs. The API allows an extension to toggle the preferences that control password saving. The privacy.websites.referrersEnabled API allows an extension to toggle the preferences that control the sending of HTTP Referrer headers.

A new API to control browserSettings has been added with an API to disable the browser’s cache. We’ll use this API for similar settings in the future.

In WebExtensions, we manage the changing of preferences and effects when extensions get uninstalled. This management was applied to chrome_url_overrides. The same management now prevents extensions overriding user changed preferences.

The theming API gained a reset method which can be called after an update to reset Firefox to the default theme.

The proxy API now has the ability to clear out a previously registered proxy.

If you’d like store a large amount of data in indexedDB (something we recommend over storage.local) then you can do so by requesting the unlimitedStorage permission. Requesting this will stop indexedDB prompting the user for permission to store a large amount of data.

The management API has added get and getAll commands. This allows extensions to query existing add-ons to spot any potential conflicts with other content.

Finally, the devtools.panels.elements.onSelectionChanged API landed and extensions that use the developer tools will find that their panels open faster.

Out of process extensions

We first mentioned out of process extensions back in the WebExtensions in Firefox 52 blog post. They’ve been a project that started back in 2016, but they have now been turned on for Windows users in Firefox 56. This is a huge milestone and a lot of work from the team.

This means that all the WebExtensions will run in their own process (that’s one process for all extensions). This has many advantages, but chief among them are  performance, security, and crash handling. For example, a crash in a WebExtension will no longer bring down Firefox. Content scripts from WebExtensions are still handled by the content process.

With the new WebExtensions architecture this change was completed with zero changes by extension developers, a significant improvement over the legacy extension environment.

There are some remaining bugs on Linux and OS X that prevent us from enabling it there, but we hope to enable those in the coming releases.

Along with measuring the performance of out of process, we’ve added in multiple telemetry signals to measure the performance of WebExtensions.  For example, it was recently found that storage.local.set was slow. With some improvements, we’ve seen a significant performance boost from a median of over 200ms down to around 25ms:

These telemetry measures conform to the standard Mozilla telemetry guidelines.


The about:debugging page got some more improvements:

The add-on ID has been added to the page. If there’s a warning about processing the add-on, that will now be shown next to the extension. Perhaps most useful to those working on their first add-on, if an add-on fails to load because of a problem, then no problem—there’s now an easy “retry” button for you to press:


Thank you once again to our many contributors for this release, especially our volunteers including: Cameron Kaiser, dw-dev, Giorgio Maone, Swapnesh Kumar Sahoo, Timothy Johnson, Tushar Saini and Tomislav Jovanovic.

Update: improved the quality of the image for context menus and removed the line about “twice as long…”.

14 comments on “WebExtensions in Firefox 56”

  1. Andreas wrote on

    Wohoo, icons for menus, just what I needed for my extension! Keep the changes coming! 🙂

  2. erosman wrote on

    Does new new API to allow icons for ContextMenu items apply to sub-menus?
    That is to say, Can you set icons for the sub-menus?

    Does above only apply to browser.menus.create (and not chrome.contextMenus.create)?

    While I actually like the shorter API names, how would that affect compatibility with Chrome which was one of the corner stones of the WebExtension implementation?

    1. Andy McKay wrote on

      Icons can be applied to sub menus.

      The contextMenus API remains unchanged to support Chrome parity. The tools_menu context is only available in the menus API which Chrome does not support.

  3. coth wrote on

    Limiting to WebExtensions will effeectively kill Firefox, as absolute majority of users are there for extensions. 90% of extensions i use are not WebExtensions. If no them, then nothing will prevent me from switching over to Edge or Chrome/Yandex from this laggy browser. Without those tones of exclusive extensions it won’t compete at all.

    If you want to kill Firefox, just tell it straight.

    1. Jorge Villalobos wrote on

      The majority of users don’t use add-ons at all, and the majority of users who use add-ons only use one or two of the most popular ones, most of which will migrate. While it’s true some users will leave Firefox because of this, we believe that the long term stability and performance gains will help Firefox become a better product and grow its users again.

      1. coth wrote on

        Blind belief. Almost all who doesn’t use extensions are alreade moved out to Chrome or Edge. So instead of addressing real problems that forced most users to leave Mozilla prefers to fix what was working and kill the rest of its users.

        1. mgol wrote on

          @coth I don’t think that’s the case. I know people who use very few extensions and have used Firefox for a long time. If it happens that one of their favorite add-ons is not ported, that may make them look for another browser. But many others won’t really notice anything.

          OTH, I hear lots of complaints about the browser speed from those users. They don’t want to change the browser, though; stability, e10s etc. will help them.

          1. Honza wrote on

            Have you considered where do the users with no/few add-ons come from? I have no evidence for this, but I feel safe to say that some part of them uses firefox because more IT savvy people (those who use many extensions and that’s what they like about firefox) told them to use it or even installed it for them. Of course most of them won’t change their browser, but new people of this sort won’t install it if you make the influential minority angry. I would honestly like to hear your opinion on this. If you can support it by data, all the better, but even just opinion would be welcome.

          2. coth wrote on

            That’s indeed the modern way of marketing. Android jumped off following satisfaction of IT pros. That’s predominant reason why Firefox still exist. Loosing core users will lead to major user outflow.

          3. coth wrote on

            And i’m on e10s since long time. It doesn’t help much. Still starts microstuttering on scrolling, freezing while loading pages in the background, freezing or rich sites, like Google Maps and Yandex Maps, hogging CPU with no tabs etc etc after some time of usage. And that’s all same even on clean profiles.

        2. Jorge Villalobos wrote on

          Nope, it’s based on hard data.

      2. Hayley Watson wrote on

        I think stability and performance gains could be achieved by trimming Firefox back to being a web browser first and foremost.

        Delegate many of its “features” to a core suite of addons that are installed by default but could be disabled (or even removed) by users if they so wish (I’ve never used this “pocket” thingy, nor do I have an urge to set up a “Firefox account” to sync tabs). The Developer Tools being an example, since so much of its functionality was implemented as the Firebug addon.

        Obviously, Firefox would need to have the APIs to support such addons – maybe that’s the sticking point: looking at how sparse WebExtension support is at lower levels there may be a shortage of enthusiasm for plumbing and everyone is concentrating on adding sexy new features.

        You remember addons? Those thingies that were meant to be one of Firefox’s big points of difference from other browsers? Go to its home page and see what the first “Feature” listed is. To cut back on what addons can do because “hardly anyone uses addons” seems like spite more than anything.

        (Disclosure: of the dozen or so extensions that are part of my workaday browsing environment, all but two are “LEGACY”.)

  4. mgol wrote on

    > Because the development period for this latest release was about twice as long as normal, we have many more updates.

    How so? The development for v55 was twice as normal as after its first 7 weeks on Nightly the Aurora channel got killed. Version 56 has spent only 8 weeks on Nightly and is now in beta.

    1. Andy McKay wrote on

      Oops, copy and paste error, will remove. Thanks for spotting.