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...
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.
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.
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.
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.
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.
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?
[1] https://addons.mozilla.org/en-US/firefox/addon/ublock-origin...
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.
If people value the old extension system that much, then it will live on in one of the FF forks. Regardless Firefox will finally get faster, more responsive, more secure, AND still have a better extension API than Blink/WebKit.
I use Firefox because it's way faster, more stable, and from an organization that I trust. I run Nightly, which means that I made the shift to Webextensions last week. My only extension that didn't have a WE version or alternative was LastPass. No surprise, since they seem to take such poor care of their extensions anyway. That's a Deal Breaker for me, so I switched to pass.
The only addon I use is LastPass. They support the new extension format just fine. I'm looking forward to the architectural changes coming in Servo, etc, which WebExtensions help make possible. I can't be the only user like me.
I'm confident Firefox will outstrip Chrome in these areas in the next year or so. But if it doesn't... it will die a slow death and the people on HN will assure us it was because NoScript didn't work anymore.
Using a fork is also bonkers. I don't trust the security of my web browsing on a fork. Most people won't, either. So Firefox will just get this nice metric saying "most people have not moved to a fork" and will be able to pat themselves in the back. But it's bogus.
As for practicality, if your daily workflow involves a browser extension that has no replacement, the options are:
- stop doing the task
- all browsing with insecure browser, no isolation
- single task with insecure browser, no isolation
- single task with insecure browser, some isolation
No they are not. Anyone who has done (or tried to do) any cross-browser extension development will attest that working with Chrome-style apis is so much faster than trying to make sense of XUL. Look at how many new extensions start life as Chrome-only these days. Chrome did to Firefox what Firefox did to IE - which had an extension mechanism that required C++ (!). Ease of development always wins, because humans are lazy. Mozilla tried for years (and failed) to match that ease of development, and then decided XUL is not a hill worth dying on - especially considering how it also held back a lot of performance-related improvements.
As others have said, it will hurt but it's worth doing if the browser is to survive. It would have probably come sooner had it not been for the FFOS distraction. Once the ecosystem is fully rebased on webextensions, then Mozilla can try an embrace-and-extinguish play if they really want to.
Web Extensions are designed in such a way that these issues can go away.
Apparently Mozilla weighs the complaints with regards to missing multiprocess support and addon security issues higher than they weigh the complaints about the old extensions going away.
I wouldn't call this decision "bonkers" either as, clearly, adding security is more important than keeping the platform stuck in the past in order to keep addons used by a minority of users working.
These strawpeople exist only in your mind.