5 ms·

>It’s only relatively recently with Electrolysis and Firefox Quantum that Firefox has regained a technical parity or superiority. And those changes depended on

>It’s only relatively recently with Electrolysis and Firefox Quantum that Firefox has regained a technical parity or superiority. And those changes depended on specifying a proper UI and Extension API which is the reason why the browser is no longer so customisable. No, they did not. Electrolysis was around before WebExtensions. Sure, Electrolysis wasn't backwards compatible and a lot of existing extensions had to rewrite part of their code to be compatible, and abandoned extensions were broken forever - or would have been once mozilla removed compat shims (unless somebody picked up the slack, which people quite often did). This was still a lot better than breaking every extension and forcing a new extremely restricted WebExtensions API that was a clone of the Chrome APIs but came with their own bugs and a lot of "TODO: implement actual API". Quantum is just a PR term. The impact of Quantum-related changes to extensions was tiny if present at all (if the extension already survived Electrolysis). The only reason that old non-webext extensions do not work anymore in Firefox at all is that they helpfully removed the actually code that would run the extension (but not really last I checked, it's still around to support mozilla-owned sideloaded/builtin extensions such as pocket). comm-central (Thunderbird, Seamonkey) even implemented their own implementation of what was removed to get (restartless) old-style extensions working again, falsifying the claim that forcing a WebExtensions-only change was a requirement to get e10s/Quantum going. Underneath it all, to this day most of Firefox is still javascript + XUL/HTML on the frontend with bridges (XPCOM, etc) to expose the C components. PS: e10s shipped in v53, "old" extensions were only removed in Quantum, which was v57 (but not really removed, as I noted, just disabled for everybody except mozilla's own stuff). I ran (and sometimes still run) a personal fork of 60esr (aka >57 ;) where I added back "old" extension support by git-reverting a few hundreds of lines of code that they removed.. That thing was Quantum too, all the Quantum perf/speed improvements were still present, and yet magically still supported all the old extensions I cared about.

causality0 6y ago
but not really removed, as I noted, just disabled for everybody except mozilla's own stuff That's fucking infuriating. You should write up a blog post about how easily you were able to turn them back on in Quantum.
- rndgermandude 6y ago
  https://gist.github.com/formerextensiondev/50f3ebf563048e75fa9d54cba1028cba https://gist.github.com/formerextensiondev/50f3ebf563048e75f... ;)
stjohnswarts 6y ago
The quantum versions of firefox are a lot more stable than the previous generation. Probably because they cut down on how many things extensions could get their grimey little fingers into. Also getting rid of more XUL helped. The new firefox is scads better than the old one. Sure I miss some extensions but that just is what it is.
- rndgermandude 6y ago
  Why do people keep saying they got rid of XUL? It's just not true. It's still there to this very day. Just look at browser.xhtml (the main browser UI file); it's a mix of HTML and XUL and the body tag is particularly interesting. <html:body xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> The first child element of that body is currently: <popupset id="mainPopupSet"> That's not HTML ;) They are trying to replace XUL with HTML and made some progress towards that. For starters they removed most or all of XBL. From the perspective of an add-on dev it wouldn't have made much of a difference, it used to be manipulating a XUL DOM, now would have been manipulating a mixed XUL/HTML DOM, in the future it would have been manipulating an HTML DOM, not much difference except for tag names and attributes names really, and the rest was js and css.
gruez 6y ago
Can you share your patches? I'm still using 52esr in some very limited contexts and an upgrade would be great
- rndgermandude 6y ago
  I never updated them beyond 60esr and that thing is outdated and insecure as well. I don't really see a point in doing so now, other than to prove I did it. But here is the important bit regardless: https://gist.github.com/formerextensiondev/50f3ebf563048e75fa9d54cba1028cba https://gist.github.com/formerextensiondev/50f3ebf563048e75f... And even back then I was too lazy to actually properly "fix" it as you can see.
atesti 6y ago
I noticed the same thing when the certificate fisasco happend: There was this one special XPI file they pushed via Normandy and I installed it manually (it was posted in some discussion forms) to get my extensions running again without restarting Firefox. If one unzips this tiny XPI, one finds javascript code which can directly install a certificate into the master store. So there is indeed a very powerful extension system available, but only to Mozilla itself who can sign such extensions. Probably all the old stuff can be brought back easily. Please put your comment in a blog! Back then I searched for these topics and found nothing
- rndgermandude 6y ago
  >Probably all the old stuff can be brought back easily. Not anymore. They removed/replaced a ton of stuff that only was used by extensions at that point. That might lower their maintenance burden, but for the most part it really was interfaces and code that hadn't been touched since the 1990, so it wasn't like it was a huge maintenance burden before. That means it wouldn't be that easy to bring back the extension system where the old extensions would be able just run unmodified. But it would be easy enough to bring back newly created old-type extensions or modify existing old-style extensions to use whatever is present now instead of the old stuff that got removed. But then again, old-style extensions had to check anyway if a new major release broke anything, and usually it did break some stuff for some extensions. It was the cost of doing business. Jetpack/WebExtensions could help with that; if you extension was simple enough to fit within their APIs. In fx60 (esr) the removal of these "old" interfaces and other things hadn't progressed much yet, so I was able to just git-revert most of the removals that affected the extensions I care about and that was enough to run those extensions again without obvious bugs.
thro1 6y ago
>I ran (and sometimes still run) a personal fork of 60esr (aka >57 ;) where I added back "old" extension support by git-reverting a few hundreds of lines of code that they removed.. Sir, I would really appreciate if you could share a patch for it.
- rndgermandude 6y ago
  https://news.ycombinator.com/item?id=24170820 https://news.ycombinator.com/item?id=24170820 ;)

causality0 6y ago

but not really removed, as I noted, just disabled for everybody except mozilla's own stuff That's fucking infuriating. You should write up a blog post about how easily you were able to turn them back on in Quantum.

rndgermandude 6y ago
https://gist.github.com/formerextensiondev/50f3ebf563048e75fa9d54cba1028cba https://gist.github.com/formerextensiondev/50f3ebf563048e75f... ;)

stjohnswarts 6y ago

The quantum versions of firefox are a lot more stable than the previous generation. Probably because they cut down on how many things extensions could get their grimey little fingers into. Also getting rid of more XUL helped. The new firefox is scads better than the old one. Sure I miss some extensions but that just is what it is.

rndgermandude 6y ago
Why do people keep saying they got rid of XUL? It's just not true. It's still there to this very day. Just look at browser.xhtml (the main browser UI file); it's a mix of HTML and XUL and the body tag is particularly interesting. <html:body xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> The first child element of that body is currently: <popupset id="mainPopupSet"> That's not HTML ;) They are trying to replace XUL with HTML and made some progress towards that. For starters they removed most or all of XBL. From the perspective of an add-on dev it wouldn't have made much of a difference, it used to be manipulating a XUL DOM, now would have been manipulating a mixed XUL/HTML DOM, in the future it would have been manipulating an HTML DOM, not much difference except for tag names and attributes names really, and the rest was js and css.

gruez 6y ago

Can you share your patches? I'm still using 52esr in some very limited contexts and an upgrade would be great

rndgermandude 6y ago
I never updated them beyond 60esr and that thing is outdated and insecure as well. I don't really see a point in doing so now, other than to prove I did it. But here is the important bit regardless: https://gist.github.com/formerextensiondev/50f3ebf563048e75fa9d54cba1028cba https://gist.github.com/formerextensiondev/50f3ebf563048e75f... And even back then I was too lazy to actually properly "fix" it as you can see.

atesti 6y ago

I noticed the same thing when the certificate fisasco happend: There was this one special XPI file they pushed via Normandy and I installed it manually (it was posted in some discussion forms) to get my extensions running again without restarting Firefox. If one unzips this tiny XPI, one finds javascript code which can directly install a certificate into the master store. So there is indeed a very powerful extension system available, but only to Mozilla itself who can sign such extensions. Probably all the old stuff can be brought back easily. Please put your comment in a blog! Back then I searched for these topics and found nothing

rndgermandude 6y ago
>Probably all the old stuff can be brought back easily. Not anymore. They removed/replaced a ton of stuff that only was used by extensions at that point. That might lower their maintenance burden, but for the most part it really was interfaces and code that hadn't been touched since the 1990, so it wasn't like it was a huge maintenance burden before. That means it wouldn't be that easy to bring back the extension system where the old extensions would be able just run unmodified. But it would be easy enough to bring back newly created old-type extensions or modify existing old-style extensions to use whatever is present now instead of the old stuff that got removed. But then again, old-style extensions had to check anyway if a new major release broke anything, and usually it did break some stuff for some extensions. It was the cost of doing business. Jetpack/WebExtensions could help with that; if you extension was simple enough to fit within their APIs. In fx60 (esr) the removal of these "old" interfaces and other things hadn't progressed much yet, so I was able to just git-revert most of the removals that affected the extensions I care about and that was enough to run those extensions again without obvious bugs.

thro1 6y ago

>I ran (and sometimes still run) a personal fork of 60esr (aka >57 ;) where I added back "old" extension support by git-reverting a few hundreds of lines of code that they removed.. Sir, I would really appreciate if you could share a patch for it.

rndgermandude 6y ago
https://news.ycombinator.com/item?id=24170820 https://news.ycombinator.com/item?id=24170820 ;)