WebExtensions, a new browser API for Firefox that Mozilla wants add-on developers to focus on once it has been released, is still on track for a Firefox 48 release.
Mozilla announced the push towards WebExtensions back in mid-2015 and made the decision back then to model the new API after Google’s Blink extension API.
Mozilla has several reasons to develop a new API, including making it easier to port extensions from and to Google Chrome and Chromium-based web browsers, making the review process easier, and making add-ons more robust when it comes to browser updates.
The initial announcement raised fear that Firefox’s superior add-on system would be severely limited with the release of WebExtensions since Mozilla announced that it would deprecate core features of the current system in the future as well.
The organization targets Firefox 48 for a first stable release of WebExtensions in the browser, and that goal has not changed yet.
Mozilla Engineering Manager Andy McKay revealed yesterday that WebExtensions are still on their way towards a Firefox 48 release.
He highlighted some of the progress that has been made by developers working on the implementation, and noted that the current state allowed an extensions such as Ghostery to be written as a web extension already.
In Firefox 48 we pushed hard to make the WebRequest API a solid foundation for privacy and security add-ons such as Ghostery, RequestPolicy and NoScript. With the current implementation of the onErrorOccurred function, it is now possible for Ghostery to be written as a WebExtension.
The first Firefox-only feature, reliable origin information, has been implemented as well which will benefit extensions such as uBlock Origin or NoScript when they are ported to the new API.
NoScript users on top of that will benefit from requestBody support which, according to McKay, will improve the performance of NoScript’s XSS filter by the factor 20 or more in some cases.
WebExtensions in Firefox 48
It is certainly the case that WebExtensions won’t replicate all functionality of Firefox’s add-on system with the initial Firefox 48 release.
If you look at the road map — a draft currently — you will notice that features won’t land in Firefox 48.
- Parity with Chrome’s Extensions API.
- Getting top 20 Chrome and Firefox add-ons to work with WebExtensions-
- Release of native.js prototype which allows add-on developers to access XPCOM or XUL among other things. You can check out this article on native.js or the bug listing on Bugzilla. One idea behind the feature is to monitor the use closely to add popular features used to the WebExtensions API.
Mozilla landed a change recently that improves Chrome compatibility. Basically, it allows for Chrome extensions to be run in Firefox without manifest changes when they are loaded via about:debugging as temporary add-ons.
One interesting and ironic side-effect of Mozilla’s WebExtensions implementation is that Firefox for Android users will be able to install (some) Chrome extensions in the web browser while Chrome users can’t.
Firefox Nightly users who want to get a feel for WebExtensions can check out example extensions that Mozilla publishes on GitHub.
I’m cautiously optimistic about the implementation of WebExtensions. What about you?