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.
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.
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...
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?
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.
Are they? The old system is holding improvements back. If they move to a superset of Chrome's they can still get Chrome add-ons and then some.
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.
The only reason to use Firefox is because many of its extensions are not possible in any other browser. Watch the market share drop after the extensions are dumbed down to Chrome level.
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.
I'm not sure if it's faster yet, but Firefox 57+ is getting very good due to all the radical changes they have been making in the last year. If you haven't checked out Firefox in a while I think you should try Firefox Nightly...
Fwiw I haven't had an issue with Lastpass, before or after the change to the extension API. They appear to be using the exact same code base as in the Chrome extension and that's fine by me.
Same here... Firefox remains my default browser for its indepence. And it is great to see it improve. Once they catch up with the Webapi I hope they keep expanding it beyond a Chrome copy.
Firefox nightly, which will end up as FF57, uses less memory than Chrome and is faster. (Windows, x64). One of the reasons this was possible was disabling the old extension system. Does it hurt? Sure. Was it needed? Yes.
Do you have any evidence this is actually true? XUL is still there, the firefox UI is still written in it and it will be for quite some time to come. I find it hard to beleive disallowing XUL extensions have significantly sped anything up.
Disallowing XUL extensions made it possible to make many underlying changes that otherwise would break a lot of them. There are plenty of long-lasting tickets on Bugzilla being finally tackled in Firefox 57.
I don't use extension any extension but i use Firefox on Desktop and Mobile. From end user wait time etc i dont see any difference between firefox and chrome. For some reason firefox is seem to be faster than chrome on mobile. I use firefox focus mostly on mobile. It would be really sad to see firefox go away as that is only one which is not tied to OS or tied to provider of webmail etc. I see firefox as a product from browser company.
I dunno - I'm a very technical user and I use a pretty vanilla Firefox mostly just because I like/trust Mozilla and don't want to support the web becoming a Webkit / Chrome monoculture.
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.
Ditto here. I use Firefox exclusively and all of my extensions are supported - OneTab, ublock origin, Lastpass. I fail to understand the narrative of "the only thing keeping FF alive is the handful of extensions that can't be ported to Chrome". I don't think the extension API is where this battle will be fought anyway. Performance and reliability are what users care about - is the browser fast to open, are pages fast to load, is it making other apps slow (memory and CPU consumption), how many tabs can I keep open, does it hang, does it crash, does any website fail to load/misbehave?
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.
Thankfully, NoScript will still work just fine - it's already a WebExtension/XUL hybrid and Firefox 57 will bring last changes needed to make it fully WebExtensionified :)
>If people value the old extension system that much, then it will live on in one of the FF forks.
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.
That's kind of a moot point when your browser handles most of your online interactions (and therefore a good chunk of your online identity, which is quite valuable to most people). Even if you isolate it as much as you can, which is a good thing to do in any case, it can still do a lot of damage without escaping the sandbox.
Yes, usage of isolated browser instances should be restricted to information within a single context or risk profile. E.g. a stateless, frequently rebooted VM for occasional use of a particular extension. Or a Bromium micro-VM for each tab, redirect, etc.
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
Most people will do #2 or #3. Those who care about security will do #4, with quality of isolation dependent on their threat model.
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.
the same people who are most vocal about this are the same people that are most vocal about not having multi process support and about having compatibility issues with extensions when the browser updates or when one extension steps onto another extension (all old-style extensions share a single namespace).
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.
>the same people who are most vocal about this are the same people that are most vocal about not having multi process support and about having compatibility issues with extensions when the browser updates or when one extension steps onto another extension (all old-style extensions share a single namespace).
Nobody is calling that out because there's an interest from the media to pretend white nationalists, nazis or whatever you want to call them are more of a menace than they actually are. A part of society play the victim card; they live off that.
Of course, the writers of that article are a part of that.
Also the point of QtQuick as an alternative to Electron is not to look native beyond the menus and dialogs.
And you probably associate Qt with Qt widgets, not QtQuick. Qt widgets actually tries to resemble and behave like native widgets, and it will let you get to that point if you actually care about that.
Most people making cross plat applications don't, which is why popular Qt widgets applications like VirtualBox and VLC don't look native, and QtQuick applications like Telegram for Desktop just ignore the desktop's HIGs completely.
The iOS version has been out for a long time, the Android version was released like a month ago or so. I'm guessing, Mozilla is just trying to promote this some more and judging by how many people here did not know of it, that seems like it was a good idea.
