WebExtensions in Firefox 53

Firefox 53 landed in Developer Edition this week, so we have another update on WebExtensions for you. With the latest release, a slew of new APIs are now available to help legacy add-on developers transition and extension developers port from other browsers.

New APIs

The majority of browser.browsingData API was implemented. This API allows you to delete data from Firefox that the user has accumulated while browsing. This includes data stored in the following places: plugin data, form data, history, cookies, downloads, passwords, service workers and the cache.

Parts of the browser.identity API was implemented. This makes it easier for extensions to integrate with OAuth providers. The getRedirectURL and launchWebAuthFlow methods have been implemented, but the areas related to Google Accounts have not been implemented.

As previously mentioned, the browser.storage.sync API had been in a testing phase. It’s passed testing now, and is turned on by default. As this feature rolls out to our users, we will continue to do more testing. It’s worth noting that the storage service is not intended for large amounts of data and comes with no guarantees around stability or uptime.

A new API, browser.contextualIdentities, landed in Firefox 53 to support the security container feature. In Firefox 52, support for contextualIdentities was added to tab and cookie stores. This API provides access to query existing identities, create, update and remove those identities.

As an example:

  .then((result) => {
    for (let identity of result) {

Outputs the existing identities:

Object { name: "Personal", icon: "fingerprint", color: "blue", cookieStoreId: "firefox-container-1" }
Object { name: "Work", icon: "briefcase", color: "orange", cookieStoreId: "firefox-container-2" }

This API is behind the same browser preference, privacy.userContext.enabled, that the rest of the contextual identity code is. We expect the API to track that preference for the moment.

Work has begun on the browser.devtools API and a major foundation of this landed in Firefox 54. We are hoping to land the remained of devtools in Firefox 54, which will allow many developer focused add-ons to work.

API Changes

Context menus have had a big improvement. They can now be applied to pageActions, browserActions, password inputs and tabs.

Screenshot 2017-01-23 14.59.01
A context menu item on a tab

A small change has been made to context menus so they now inherit the submenu contexts from their parent by default.

There was a previous issue where the requestBody on webRequest was not available on release versions of Firefox due to concerns about performance. Those issues have now been resolved and this functionality will be available in release from Firefox 53 onwards.

There was a significant increase in performance for browser.tabs.query which will speed up queries when a large number of tabs exist. Also in tabs, the onUpdated event will now fire when the title of a tab changes.

To complete the browser.sessions API, the browser.sessions.onChanged event landed. This allows extensions to tell when recently closed tabs or windows are changed.

You can now insert CSS into Firefox as a user sheet. As an example:

browser.tabs.insertCSS({..., cssOrigin: "user'})

Finally, function keys now work in commands.


With Firefox 53, required permissions have been enabled for WebExtensions add-ons. The permissions dialog is behind a preference while we complete QA on the feature. We hope that permissions will be turned on by default for Firefox 54. To activate permissions, please create the preference: extensions.webextPermissionPrompts as a boolean and set it to true.

When installing an add-on, a user will get a prompt like this:

Screenshot 2017-01-23 16.20.16
Installing an add-on

Updates will proceed normally, unless you update the permissions of your add-on. In that case  the add-on update will be staged. Unlike Chrome, the existing add-on will continue to work and will not be disabled. Firefox users will get a notification in the hamburger menu:

Screenshot 2017-01-23 17.23.12
An update that includes permission changes to an add-on.

And when they click on it, they will see a new permissions dialog outlining the changes. In this example, it shows that I have added the permission nativeMessaging to the add-on:

Screenshot 2017-01-23 17.23.02
The permission prompt on an update

Finally, if your add-on is being sideloaded, the notification will also change to a new flow. An item in the hamburger menu is shown (similar to above), followed by a slightly different permission prompt:

Screenshot 2017-01-23 17.39.55
A sideloaded extension

This is a big feature and many details are currently being finalized. So feedback or bugs are encouraged so we can solve any problems before Firefox 54.

New contributors

A lot of contributors helped out on this release, so a big thank you to them! They are: Srivatsav Gunisetty, Laurent, André Bargull, Rob Wu and Tomislav Jovanovic.

12 comments on “WebExtensions in Firefox 53”

  1. Peter wrote on

    Any plans for runtime permissions instead of the “accept all or don’t install” approach? With that I mean permission controls similar to iOS and Android (6.0+) where apps request permissions on demand instead of all at once at install time.

    With the current approach developers tend to request more permissions than necessary (or simply all of them) to avoid the permission update warning dialog.

    When doing the switch to WebExt please do not simply copy Chrome but also use this opportunity to improve the situation.

    1. Andy McKay wrote on

      Optional permissions are also being implemented. Please follow bug https://bugzilla.mozilla.org/show_bug.cgi?id=1197420

      1. Peter wrote on

        Yes, I know about Chrome’s optional permissions and I know that most extensions do not use them. My question was about making ALL permissions optional (= request at runtime) instead of up front.

        That way users can decide on a case by case basis which permissions to allow.

  2. cicruedd wrote on

    Could you clarify:
    “Updates will proceed normally, unless you update the permissions of your add-on. In that case the add-on update will be staged. Unlike Chrome, the existing add-on will continue to work and will not be disabled. Firefox users will get a notification in the hamburger menu.”

    Are you saying:
    a) the addon gets the new permissions by default, until the user interacts with the permissions dialog;
    b) the old version of the addon is used until the user approves the permissions for the updated version of the addon;
    c) the updated version of the addon is installed right away, even though it may not function properly without certain permissions; or
    d) something else?

    Also, does the notification appear anywhere besides the hamburger menu (I would hope at /least/ it also appears in about:addons)? What about users who have hidden the hamburger menu? Can there be an about:config preference to make the permissions prompt come up on updates as it does when initially installing an addon (or, preferably, at next browser startup)?

    1. Andy McKay wrote on


      There will be a message on upgrade in about:addons as well, but you can’t actually hide the hamburger menu through normal Firefox customisation.

  3. firefoxer wrote on

    1. Is anything in the works to at least give read access to everything in about:config?
    I wouldn’t mind if it required a permission, preferably with 2 options, config-readonly and config-full or something like that.
    2. any plans to make webRequest.onBeforeRedirect blockable? Or do you have any tips on how to achieve intercepting every request? I’d like to re-create the NoRedirect addon with WebExtensions.
    Even better would be an example addon which does that 😉

    Thank you

    1. Andy McKay wrote on

      1) no 2) don’t know, could you file a bug about it?

  4. Wes wrote on

    Are we finally going to have the ability to add icons for context menu items?
    That has been a promised features that’s been in the Beta and Nightly versions, but hasn’t seemed to carry over to the actual release version yet.

    What’s the hold up?

    1. Andy McKay wrote on

      I know of no such promise, is there a bug or something you can point me to?

  5. Eric Guerin wrote on

    Reading continuing comments on this “WebExtensions” path forward, it sounds like developers are going to just jump ship and discontinue products. Posted today from the maker of Tab Groups, which is one of the primary reasons to use FireFox over competitors:
    “I cannot continue working on my add-ons anymore. I’m sorry, but it’s time.” — Quicksaver – Luís Miguel http://fasezero.com/addons/

    I think Mozilla needs to re-evaluate their decision, and if they still want to move forward with this move, please bring Tab Groups and several other key features back into the core of FireFox, otherwise there will be no reason to use it over Chrome.

  6. Mark Bauermeister wrote on

    Was any of the remaining addon-sdk functionality changed/deprecated/removed for this release (compared to Aurora 52.0a1), or can I safely upgrade my fork of gecko-dev/aurora?

  7. Philippe Vigneau wrote on

    totally agree with Eric Guerin… again an incredible decision…