We lastupdated you on our progress withWebExtensions when Firefox 47 landed in Developer Edition (Aurora), and today we have an update forFirefox 48, which landed in Developer Edition this week.
With the release of Firefox 48, we feel WebExtensions are in a stable state. We recommend developers start to use the WebExtensions API for their add-on development. Over the last release more than82 bugs were closed on WebExtensions alone.
If you have authored an add-on in the past and are curious how it’s affected by the upcoming changes, please use the lookup tool . There is also awiki page filled with resources to support you through the changes.
The options v2 API is now supported so that developers can implement an options UI for their users. We do not plan to support the options v1 API, which is deprecated in Chrome. You can see an example of how to use this API in the WebExtensions examples on Github.
In Firefox 48 we pushed hard to make the WebRequest API a solid foundation for privacy and security add-ons such asGhostery,RequestPolicy andNoScript. With the current implementation of theonErrorOccurred function, it is now possible for Ghostery to be written as a WebExtension .
The addition of reliableorigin information was a major requirement for existing Firefox security add-ons performing cross-origin checks such as NoScript oruBlock Origin. This feature is unique to Firefox, and is one of our first expansions beyond parity with the Chrome APIs for WebExtensions.
AlthoughrequestBody support is not in Firefox 48 at the time of publication, we hope it will be uplifted. This change to Gecko is quite significant because it will allow NoScript’s XSS filter to perform much better as a WebExtension, with huge speed gains (20 times or more) in some cases over the existing XUL and XPCOM extension for many operations (e.g. form submissions that include file uploads).
We’ve also had the chance to dramatically increase our unit test coverage again across the WebExtensions API, and now our modules have over 92% test coverage .
Content Security Policy Support
"script-src 'self'; object-src 'self';"
For example, to load scripts from example.com, the manifest would include a policy configuration that would look like this:
"content_security_policy": "script-src 'self' https://example.com; object-src 'self'"
Please note: this will be a backwards incompatible change for any Firefox WebExtensions that did not adhere to this CSP. Existing WebExtensions that do not adhere to the CSP will need to be updated.
To improve the compatibility with Chrome,a change has landed in Firefox that allows an add-on to be run in Firefox without the add-on id specified. That means that Chrome add-ons can now be run in Firefox with no manifest changes using about:debugging and loading it as atemporary add-on.
Support for extensions with no add-on id is being added toaddons.mozilla.org (AMO) and our other tools, and should be in place on AMO for when Firefox 48 lands in release .
With the release of Firefox 48 we are announcing Android support for WebExtensions. WebExtensions add-ons can now be installed and run on Android, just like any other add-on. However, because Firefox for Android makes use of a native user interface, anything that involves user interface interaction is currently unsupported (similar to existing extensions on Android).
In Firefox 45 the ability to load add-ons temporarily was added to about:debugging. In Firefox 48 several exciting enhancements are added to about:debugging.
If your add-on fails to load for some reason in about:debugging (most commonly due to JSON syntax errors), then you’ll get a helpful message appearing at the top of about:debugging. In the past, the error would be hidden away in the browser console.
It still remains in thebrowser console, but is now visible that an error occurred right in the same page where loading was triggered.
You can now debug background scripts and content scripts in the debugging tools. In this example, to debug background scripts I loaded the add-on bookmark-it from theMDN examples. Next click “Enable add-on debugging”, then click “debug”:
You will need to accept the incoming remote debugger session request. Then you’ll have a Web Console for the background page. This allows you to interact with the background page. In this case I’m calling the
This will call the
toggleBookmark function and bookmark the page (note the bookmark icon is now blue. If you want to debug the
toggleBookmark function, just add the
debugger statement at the appropriate line. When you trigger
toggleBookmark , you’ll be dropped into the debugger:
You can now debug content scripts. In this example I’ve loaded the beastify add-on from theMDN examples using about:debugging. This add-on runs a content script to alter the current page by adding a red border.
All you have to do to debug it is to insert the debugger statement into your content script, open up the Developer Tools debugger and trigger the debug statement:
You are then dropped into the debugger ready to start debugging the content script.
As you may know, restarting Firefox and adding in a new add-on is can be slow, so about:debugging now allows you to reload an add-on. This will remove the add-on and then re-enable the add-on, so that you don’t have to keep restarting Firefox. This is especially useful for changes to the manifest, which will not be automatically refreshed. It also resets UI buttons.
In the following example the add-on just calls
setBadgeText to add “Test” onto the browser action button (in the top right) when you press the button added by the add-on.
Hitting reload for that add-on clears the state for that button and reloads the add-on from the manifest, meaning that after a reload, the “Test” text has been removed.
This makes developing and debugging WebExtensions really easy. Coming soon,web-ext, the command line tool for developing add-ons, will gain the ability to trigger this each time a file in the add-on changes.
There are also lots of other ways toget involved with WebExtensions, so please check them out!