Archive for the WebExtensions Category

Since last time I wrote about WebExtensions, a lot has been going on: for instance, I used to link a Mozilla Wiki article, and as you can see now I'm linking a full featured MDN entry :)

In the meanwhile, I've been among other things hacking the WebExtensions code itself to make it suitable for eventually porting my own extensions, NoScript and FlashGot, and all those which share similar requirements.

The key WebExtensions API needed by adblockers (one of the most popular browser extensions category), by anti-trackers like Ghostery and, of course, by security add-ons like NoScript, is WebRequest. Its first implementation as a JavaScript module (still the foundation of the current one, which is a thin wrapper over it) even predates WebExtensions themselves: genius e10s hacker Bill McCloskey started it as a brave experiment to see how realistic could have been migrating Adblock/Ghostery/NoScript to the still just rumored "next thing" in add-on development.

Unfortunately, the way this API was originally implemented imposed harsh limitations, both in Chrome compatibility and, more annoyingly, in suitability for the very kind of add-ons it was meant to support. But we've got good news: I've recently landed a couple of patches (after a long time spent away from Mozilla's code repositories), paving the way to the removal of the remaining Chrome incompatibilities and for the addition of new divergent features required by NoScript & Co. which by the way, if ever borrowed in Chromium, could even finally make a NoScript porting on Google's browsers and derivatives possible.

More specifically, Firefox 47 adds:

  • The requestId property in every WebRequest event, allowing listeners to track individual requests across their entire lifecycle (yes, it's incredible we had not implement it yet, and it was the main blocker for Ghostery as a WebExtension).
  • Reliable HTTP headers manipulation - they can be examined, deleted, added or modified both in requests (by onBeforeSendHeaders listeners) and responses (onHeadersReceived) as plain JavaScript arrays of name-value pairs.
  • HTTP response status code and raw status line reporting - without this, it was almost impossible telling the type of a redirection or even whether a request succeeded or failed and how.
  • Coming very soon:

    • The onErrorOccurred event (patch ready, will surely land in 48), also needed by Ghostery.
    • The requestBody property, which allows onBeforeRequest listeners to analyze the payload of POST and PUT requests and is required by NoScript's XSS filter.
    • An "origin" property, which is required not just by many features of NoScript's but also by other add-ons such as RequestPolicy.

    I'm very satisfied with the work done so far, and as soon as the 3 features above are completed, I'm ready to take on other areas where the Chrome extensions API (hence, for obvious reasons, WebExtensions in their present state) are severely lacking, such as script execution control and fine-tuned content blocking, which still prevent NoScript from migrating.

    During the past weeks I've grown intimate with the WebExtensions API source code and familiar enough with the "modern" Firefox development workflow. I'm sure this incoming spring will be a most interesting time, and I'm confident that summer will come with a brand new NoScript, reborn as a WebExtension :)

WebExtensions are making some people happy, some people angry, many people ask questions.
Some of the answers can be found here, more to come as add-on developers keep discussing this hot topic.
My favourite one: No, your add-ons' ability and your own creativity won't be limited by the new API.

Bad Behavior has blocked 1000 access attempts in the last 7 days.