Hacker News Reader

Comment by Animats | Hacker News Reader

Only about 20% of Firefox add-ons have been converted to WebExtension format.

One of the headaches is that access to local storage is asynchronous (in the "promise" sense) in WebExtensions. As a result, if you want something based on stored data such as a stored script or a blocklist to happen early, during page load, you can't get it to run soon enough. This breaks Greasemonkey[1] and NoScript.[2] WebExtensions needs some extensions for them to work. The new features appear to be coming, but represent divergence from cross-platform WebExtensions, and they may not be working in the release version before the XUL death date.

Fortunately, my own add-on didn't need anything that isn't working yet, so I had a successful port.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1332273 [2] https://blog.mozilla.org/addons/2017/08/01/noscripts-migrati...

View on HN

The 20% figure doesn't say that much - you'd need to know how many of the extensions used most often are ported. I can very much imagine there being a long tail of extensions that nobody uses.

Also take into account how many Chrome extensions are ported over now that it's easy. For example, the only extension I use that won't get ported over is VimFx, but Vimium has now become available which does exactly the things I used VimFx for.

https://arewewebextensionsyet.com/

Unfortunately 75%+ of the most used extensions either arnt ported, wont be ported, or cant be ported.

The situation is pretty grim, mozilla really needs to delay this move, web extensions arnt capable of supporting the functionality lots of these addons require, and its not like XUL is even going away in the near/midterm, this is purely an administrative decision.

If they plow forward anyways its going to really, really hurt firefox.

Although I don't expect it, I can imagine Mozilla delaying it a bit if they have reasonable belief most of those will be ported in a reasonable amount of time.

That said, saying it's an administrative decision really misses the point. XUL support hampers performance, slows down Firefox development, and includes security issues. Those are serious reasons for moving away from them. They might not weigh up to the benefits to you, but you can't deny that they're there.

They won't delay it since they've already begun breaking the old XUL extensions API in order to make room for new improvements. This is getting quite tiresome at this point -- extension devs have had over a year to port. If the extension devs are targeting Chrome too, it's easier to use WebExt than XUL anyway, and if they haven't spent this time to engage with Mozilla about expanding the WebExt spec so their extension is not possible in WebExt, the fault lies with the extension dev.

I think thats pretty unfair when mozilla has been straight up refusing to implement webextension equivilents to XUL based functionality that a lot of addons depend on.

Such as the fact there is no way to enumerate what sites have html5 local storage stuff stored, thus no way to control or clear it on a per site basis, and they are not interested in changing this, rendering an addon like what self destructing cookies does imposisble...

https://bugzilla.mozilla.org/show_bug.cgi?id=1329745

Or the ability for extensions to construct permission sandboxing

https://bugzilla.mozilla.org/show_bug.cgi?id=1353468

There is objectively a LOT of functionality that is just plain never going to be implemented, thats far from the fault of the extension authors.

Many have been trying to work with mozilla to push in the functionality they need, but if they just get disregaurded and ignored what are they supposed to do exactly?

Don't try to place the blame for this on the extension authors.

There is that. For big-name extensions like UBlock Origin and Greasemonkey, there's a Mozilla bug which is used as a tracker for Firefox-side issues which need to be fixed. Lesser extensions don't get that kind of attention.

When I was porting my extension, my big worry was "is there going to be something I need to do that doesn't work?" But there were no show-stopper bugs.

> if you want something based on stored data such as a stored script or a blocklist to happen early, during page load, you can't get it to run soon enough. This breaks Greasemonkey[1] and NoScript.[2]

How does UBO work? Or is it broken too?

EDIT: Thanks for the replies. I know there's a webext version of UBO, but that doesn't really explain why the problem I quoted would affect noscript and greasemonkey but not ubo?

There were problems, but they seem to be past them.[1]

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1309926

UBlock Origin has a working version in the dev channel [1]

[1] https://addons.mozilla.org/en-US/firefox/addon/ublock-origin...

At least the ones I use are all migrating and the issue at the moment is more, that new versions are pushed to the Mozilla store but waiting for approval - If Mozilla doesn't speed up that process, a lot of extensions will probably be missing for a while.

The only really sad thing is that pentadactyl/vimperator won't work at all and require complete rewrites to cover at least part of the old functionality.

Reply on news.ycombinator.com