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.

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.onChangedevent landed. This allows extensions to tell when recently closed tabs or windows are changed.

Permissions

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:

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:

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:

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:

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.

12 responses

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.

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. 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 😉

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.

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.