Updated on 28th August 2015

Many of you have read a certain announcement about the future of Firefox's add-ons and are worried about some extensions, including NoScript, being deeply rooted into those Mozilla's core technologies, such as XPCOM and XUL, which are going to be deprecated.

Developers and users are also concerned about add-ons being prevented from exploring radically new concepts which would require those "super powers" apparently taken away by the WebExtensions API.

I'd like to reassure them: Mozilla is investing a lot of resources to ensure that complex and innovative extensions can prosper also in the new Web-centric ecosystem. In fact, as mentioned by Bill McCloskey, at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API, which is going to be augmented and shaped around their needs and with their contributions.

I've just published a proposal, tentatively called native.js, to "embrace & extend" the WebExtensions API: all the interested parties are invited to discuss it on discourse.mozilla-community.org.

28th August 2015 Update

native.js has been linked in the Web Extensions FAQ and now there's a Bugzilla entry about implementing a native.js prototype (please keep the discussion on Discourse rather than on Bugzilla, though!!!).

13 Responses to “WebExtensions API & NoScript”

  1. #1 Gilding says:

    It is sad to see you so supportive of that change.

    Looking through the NoScript source I see various code which replaces/intercepts internal functions (notificationBoxPatch, wrapBrowserAccess, Hacks, noscriptBM.js), something that definitely won't be supported in the new model.

    Sure the Firefox devs could provide APIs so you don't need to replace those functions (why haven't they done so a long time ago?), but what happens if you notice that another functions needs to be replaced to make something work? Waiting at least 18 weeks for a new API (if at all) seems disastrous.

  2. #2 Giorgio says:

    @Gilding: my native.js proposal is meant to handle all the situations, like the ones you mention, which require low-level hacks (either for backward compatibility or for crazy innovations), without waiting for an "official" API to be designed and implemented by Mozilla. Using native.js's meta-API feature, you would implement your own API and even offer it to other add-ons developer with similar needs. On the other hand, Mozilla could build on your work as a baseline to be polished and eventually included in the "stable" WebExtensions API, where it would be guaranteed stability and forward-compatibility, even against disruptive changes in the underlying platform.

    The aim is ensuring that the browser has the agility to evolve faster and safer, while add-ons keep delivering innovative features.

    If you've got objections, doubts or counter-proposals, you're welcome to elaborate, possibly by commenting on the proposal itself.

    Thank you!

  3. #3 Gilding says:

    -> https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/
    "However, we don’t want this to become another feature like require('chrome') in Jetpack, which is used by virtually every add-on."
    I don't see how that would make something like native.js a possibility.

  4. #4 Giorgio says:

    @Gilding: Would knowing that native.js is a concrete possibility (that's the point of discussing it publicly) make you more comfortable and hopeful?

  5. #5 Gilding says:

    And what would be the point be in deprecating current extensions then? In which form wouldn't native.js cause the same problems which are the reason for the deprecation? Why not simply prompt for "browser super powers" for current extensions also?

  6. #6 Giorgio says:

    The point of deprecating current extensions is that -- aside notable and laudable exceptions which put a lot of study and scaffolding work into handling the Electrolysis MessageManager gory details and completely refactored their code splitting it aside their processes, like I had to do once with NSA++ -- they're already broken by Electrolysis. And those which appear not to be broken rely (probably ignoring it) on compatibility shims created by Mozilla in a huge effort of good will, shims that need to go away as soon as possible because they're awfully slow. And all those extensions, both the best and the worst, are going to break anyway when Mozilla decides it's time to unfreeze those technologies, such as Rust, Servo, browser.html, which would help Firefox to be on top of the innovation, security and speed games and which are waiting in the fridge for compatibility sake.

    The WebExtensions API is Electrolyisis-friendly from day 1 and promises to follow even the most radical platform changes keeping a stable interface. On top of it, native.js provides a mechanism to experiment new things and prototype new APIs to be used immediately. The difference from require('chrome') is that you don't get any guarantee that your native.js code won't break as soon as the platform evolves: you still have the option to update it in time (you'll get a early warning) and/or to lobby for inclusion in the WebExtensions API, which transfers the compatibility burden to Mozilla (BTW, it would be nice if you became the owner of that feature anyway, since you proposed it and provided its first implementation).

    How does that sound?

  7. #7 Thrawn says:

    @Gilding: If NoScript makes extensive use of native functions, and yet Giorgio is happy about WebExtensions, then I'm confident that he'll be able to port whatever he needs to.

  8. #8 John Gordon says:

    I started using noscript with tor. It's unsettling all the tracking being done online, by the government and private companies. I just wanted to say Thank you for what you have done. I will contribute soon.

  9. #9 Me says:

    I think it would be nice to have a "warning mode" on NoScript, so that when a potentially malicious script is encountered, a pop up appears.

    How about this? http://goo.gl/KxtNoO

  10. #10 онлайн казино живой дилер says:

    Благодарю за пересказ очевидных вещей.

    Осознал внятную мысль. Из текста следует, что нажиться уже завтра просто?
    Чувствую себя от этого несчастным.

  11. #11 Thrawn says:

    My real concern with this development is not so much for NoScript, which has active development and a large userbase, but for the hundreds and thousands of addons that don't receive so much time and care, may have developers who wouldn't know how to port them to WebExtensions, but which currently work and provide value to their users.

    All of them will be killed if XUL support is removed.

  12. #12 Giorgio says:

    @Thrawn: there' an add-on developers outreach task force at Mozilla to help them survive. You could help, too, by compiling and giving me a list of add-ons which are unique, not super-popular but useful to a niche and lacking of any Chrome counterpart which could serve as an easy-to-port replacement.

  13. #13 tom lee says:

    ABE in Noscript needs more description. Check is enough?

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