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 :)

7 Responses to “WebRequest: Where We're, Where We're going”

  1. #1 superkuh says:

    Will you be maintaining the existing Firefox NoScript extensions or abandoning them for only the to-be-created Chrome/WebExtensions compatible version?

  2. #2 Giorgio says:

    NoScript for Firefox is and will be my top priority, if nothing else because I am a Mozilla hacker and if I need some specific unsupported feature it's much easier for me to obtain it on this platform. An hypothetical Chrome version would be just a (much convenient) side effect. XUL NoScript, though, is gonna be left behind as soon as the WebExtension version reaches feature parity, because maintaining a version for obsolete platforms only would be unsustainable for me. Forks, of course, would be welcome though.

  3. #3 Will says:

    I don't know how the timing will work out, but I hope you will support XUL NoScript at least until WebExtensions NoScript works in ESR Firefox.

  4. #4 Thrawn says:

    "XUL NoScript, though, is gonna be left behind..."

    This will surely impact all non-Firefox platforms :(. Forking is all very well, but I don't think anyone else knows the NoScript codebase well enough to easily take that on.

  5. #5 sosad says:

    well, to have a look at what might come with FF, i try the 64bit Nightly on a second partition.. and it seems the most recent one (48.0a1) just disabled noscript, claiming the install was not correct. might well be they don't have the XUL one working since Monday, Mar 15th. it worked until then.

  6. #6 AnonymousCoward says:

    NS is above all else developed for security.
    Giorgio has given more than 10 years of continuous support of code that of its nature has to leverage client power back at server power. That's a lot of hacking at the guts of any code.
    It also implies a rather large commitment; Giorgio had to hack Fx intensively and continuously to develop NS. Even though in recent years he probably had enough of the XUL Fx hacking under his belt to be able to spend his *free as in beer* time looking at backwards compatibility, it seems to me that it's unfair and moreover unrealistic to expect Giorgio to even consider back support of XUL now that he's advised his confidence of being able to deliver NS to the new Fx.

    There's no question in my mind that a browser without NS is no browser at all, so
    it really doesn't matter which browser Giorgio chooses to hack - just as long as he continues to do so.
    Kudos Giorgio and thanks to Mozilla for facilitating the WebExtensions collaboration needed for NS to continue under the Moz umbrella.

    No, I am not a Moz spokesperson - just one more mug out here in client land.

  7. #7 meme says:

    + i am waiting for this

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