Why did Mozilla remove XUL add-ons? (2020)(yoric.github.io)
yoric.github.io
Why did Mozilla remove XUL add-ons? (2020)
https://yoric.github.io/post/why-did-mozilla-remove-xul-addons/
107 comments
> As we read this, let us reflect that this reasonable and mature position resulted in a ~2% market share [0]
Throwaway since I used to work at Mozilla:
You are 100% wrong in your analysis, metrics have shown over and over again that people didn't use XUL addons (even if you add the people disabling telemetry).
The real culprits to Mozilla's market share downtrend are:
1. Google started advertising Chrome on every single property they own (e.g. Google search) and made deals to pre-install Chrome on new computers. On mobile devices with Android it's even worse: if the default is good enough, why change?
2. During that time Firefox was playing catch-up: for a long time it was multiple times slower and crashier (and still is to a small extent) due to its older architecture. Meanwhile, Google with 2-3x more engineers on Chrome can deliver a better browser and pump out new w3c standards every month.
3. The Mozilla leadership reacted too late, too slow and with the failure of Firefox OS they've become risk averse and they'd rather become irrelevant than dead.
Throwaway since I used to work at Mozilla:
You are 100% wrong in your analysis, metrics have shown over and over again that people didn't use XUL addons (even if you add the people disabling telemetry).
The real culprits to Mozilla's market share downtrend are:
1. Google started advertising Chrome on every single property they own (e.g. Google search) and made deals to pre-install Chrome on new computers. On mobile devices with Android it's even worse: if the default is good enough, why change?
2. During that time Firefox was playing catch-up: for a long time it was multiple times slower and crashier (and still is to a small extent) due to its older architecture. Meanwhile, Google with 2-3x more engineers on Chrome can deliver a better browser and pump out new w3c standards every month.
3. The Mozilla leadership reacted too late, too slow and with the failure of Firefox OS they've become risk averse and they'd rather become irrelevant than dead.
I shall clarify:
There is nothing wrong with having an irrelevant share of the market. Most software I use has a market share in the 0-2% range.
However, Mozilla screwed up quite badly because their response to being pushed out of the mainstream was to gut everything that would have made them an interesting niche player. Their niche could have been "OK, this isn't Chrome but you get an IRC client and a bunch of crazy capabilities that are fun at lan parties. We'll train the next generation of devs by giving them cool capabilities to experiment with!". Instead, the niche is the worse version of Chrome.
> metrics have shown over and over again that people didn't use XUL addons
Now the metrics show people don't use Firefox. Funny thing, life. I think it was a bad time to make a metric-driven decision.
There is nothing wrong with having an irrelevant share of the market. Most software I use has a market share in the 0-2% range.
However, Mozilla screwed up quite badly because their response to being pushed out of the mainstream was to gut everything that would have made them an interesting niche player. Their niche could have been "OK, this isn't Chrome but you get an IRC client and a bunch of crazy capabilities that are fun at lan parties. We'll train the next generation of devs by giving them cool capabilities to experiment with!". Instead, the niche is the worse version of Chrome.
> metrics have shown over and over again that people didn't use XUL addons
Now the metrics show people don't use Firefox. Funny thing, life. I think it was a bad time to make a metric-driven decision.
There is a huge difference between a world with a usable 2% browser (20% in Germany) and a 0.02% browser you are describing, that would in all likelihood also be incapable of actually keeping sufficient compatibility with Chrome to still actually, you know, browse the web.
This sounds terrible.
I'd be happy with a Firefox that didn't have stupid UI mistakes like making it impossible to tell which tab is selected. Or which didn't lose all my tabs in a crash. Getting the basics right matters.
I'd be happy with a Firefox that didn't have stupid UI mistakes like making it impossible to tell which tab is selected. Or which didn't lose all my tabs in a crash. Getting the basics right matters.
> You are 100% wrong in your analysis, metrics have shown over and over again that people didn't use XUL addons (even if you add the people disabling telemetry).
And yet, the anecedata here on HN suggests that you are probably surrounded of those people that did use them. Deciding that suddenly the longstanding demographic of Firefox users - tech people - are no longer relevant to the company strategy was a shitty move, and it drove them away.
And yet, the anecedata here on HN suggests that you are probably surrounded of those people that did use them. Deciding that suddenly the longstanding demographic of Firefox users - tech people - are no longer relevant to the company strategy was a shitty move, and it drove them away.
I did use them and transition was way smoother than I feared.
I did use a few of them and I am still irritated every time I run Firefox that some simple things don't (and AIUI can't) work any more. At least real ad blocking still works and they're probably not foolish enough to change that. And there are still some significant privacy advantages without the old plugins like having the option for separate search and location bars.
I still miss Tab mix plus.
I am aware there is some mucking around that I could perform to maybe get it working, but it probably involves changing some settings that I'm not sure I should.
I am aware there is some mucking around that I could perform to maybe get it working, but it probably involves changing some settings that I'm not sure I should.
I wanted to chime in here that I agree with (1) as well.
In the time before Chrome, Firefox market share grew in part because of how aggressively Google and the rest of the web advertised for them. However, that market share peaked and shrunk after Chrome was released; Google shifted _all_ of their advertising from Firefox for Chrome.
In the time before Chrome, Firefox market share grew in part because of how aggressively Google and the rest of the web advertised for them. However, that market share peaked and shrunk after Chrome was released; Google shifted _all_ of their advertising from Firefox for Chrome.
I have been the person who made the final decision about default browsers for a company several times. You'd better believe after you killed xul I never chose firefox again.
What is really astonishing is the denialism that Mozilla as an organization, and it's individual employees and contributors, engage in, along with the associated toxic positivity and emotional abuse heaped upon the userbase.
Mozilla has made a number of obvious mis-steps, but not only is there virtually no acknowledgement of the negative impact of these mis-steps, but they are often falsely lauded as successes, when they are obviously massive failures.
The user is then confronted with language typically associated with emotional abusers, such as "We know how much you love Firefox!". Googling the words "you love" against Mozilla's website turns up hundreds of bizarre examples.
Mozilla has made a number of obvious mis-steps, but not only is there virtually no acknowledgement of the negative impact of these mis-steps, but they are often falsely lauded as successes, when they are obviously massive failures.
The user is then confronted with language typically associated with emotional abusers, such as "We know how much you love Firefox!". Googling the words "you love" against Mozilla's website turns up hundreds of bizarre examples.
Private: it connects to Google servers for "safe browsing" and was pushing hard for dns over http to circumvent the user supplied name server.
Security: as soon as it starts it connects to e100.net.
Configurable: say what ? (configurability died with the XUL).
I only use it as a Chrome replacement, when webpages don't play nice in PaleMoon or Seamonkey.
I need to set up a PiHole to make it behave but a minicomputer with ethernet interfaces and a resonable price is hard to find.
Security: as soon as it starts it connects to e100.net.
Configurable: say what ? (configurability died with the XUL).
I only use it as a Chrome replacement, when webpages don't play nice in PaleMoon or Seamonkey.
I need to set up a PiHole to make it behave but a minicomputer with ethernet interfaces and a resonable price is hard to find.
It is just not that serious.
> As we read this, let us reflect that this reasonable and mature position resulted in a ~2% market share
I would disagree.
Many other changes together lead to this outcome.
Many by Mozilla, some not by Mozilla, some you could say Google actively abusing their power to sabotage them.
AFIK the amount of people stopped using Firefox because of XUL isn't to big, you could say a vocal minority.
The problem is compatibility with websites in aspects unrelated to XUL, mostly due to it being way to hard to be bug and feature compatible with chrome and even back then most web applications being written for chrome only.
Two major pain points which make people stop using Firefox would be 1) media support, which partially is the fault of stupid patent issues and partially because programs relaying too much on non standardized aspects 2) CORS, mainly due to Chrome last minute deciding not not implement the standard as standardized and forcing an exception into the standard to still be compliant.
The 2nd point is I think the most common reason I run into cases of web sides not working at all. While I very well do understand that Mozilla devs don't want to make their browser less secure, I don't think they have any other choice and should have done so years ago.
The 1st point is complicated as it involves patents to codecs and the pain of video codec drivers as well as companies like Slack or Teams refusing to even _try_ to work with Firefox when it comes to video calls even through it should work in most cases. This is a major problem and against all best web practices (also a lot of smaller companies which have way less resources have Firefox support for such use cases....).
But IMHO the web needs a cut, it's unacceptable that it's way easier to write a production ready new OS from scratch then a browser which is an essential tool.
I would disagree.
Many other changes together lead to this outcome.
Many by Mozilla, some not by Mozilla, some you could say Google actively abusing their power to sabotage them.
AFIK the amount of people stopped using Firefox because of XUL isn't to big, you could say a vocal minority.
The problem is compatibility with websites in aspects unrelated to XUL, mostly due to it being way to hard to be bug and feature compatible with chrome and even back then most web applications being written for chrome only.
Two major pain points which make people stop using Firefox would be 1) media support, which partially is the fault of stupid patent issues and partially because programs relaying too much on non standardized aspects 2) CORS, mainly due to Chrome last minute deciding not not implement the standard as standardized and forcing an exception into the standard to still be compliant.
The 2nd point is I think the most common reason I run into cases of web sides not working at all. While I very well do understand that Mozilla devs don't want to make their browser less secure, I don't think they have any other choice and should have done so years ago.
The 1st point is complicated as it involves patents to codecs and the pain of video codec drivers as well as companies like Slack or Teams refusing to even _try_ to work with Firefox when it comes to video calls even through it should work in most cases. This is a major problem and against all best web practices (also a lot of smaller companies which have way less resources have Firefox support for such use cases....).
But IMHO the web needs a cut, it's unacceptable that it's way easier to write a production ready new OS from scratch then a browser which is an essential tool.
> AFIK the amount of people stopped using Firefox because of XUL isn't to big, you could say a vocal minority.
The amount of Firefox's entire userbase isn't "to big" either, that is part of the problem. They can't put out a good web browser to give the silent majority something they want, they can't make in interesting web browser to give the vocal minority something they want.
Why are they building this web browser? Who is supposed to use it? The only argument I've heard is from people who want to support an open rendering engine, which has to be a smaller group than people who want support for weird extensions. And the Chrome-based engines are open already making the whole thing a bit moot.
The Mozilla corporation turns out not to have an interesting plan for Firefox. So cutting extension developers out from trying new things was a massive blunder that has basically doomed them to their current path - they don't know how to make an interetsing web browser and they've locked anyone else out from using their toys. Konqueror of all browsers spawned this massive ecosystem of successful spin-offs [0]. Mozilla failed to do anything useful.
Thank goodness the KDE devs were on their game, I suppose. Turns out in hindsight they were building the OSS flagship and foundation of the modern internet.
[0] https://upload.wikimedia.org/wikipedia/commons/7/74/Timeline...
The amount of Firefox's entire userbase isn't "to big" either, that is part of the problem. They can't put out a good web browser to give the silent majority something they want, they can't make in interesting web browser to give the vocal minority something they want.
Why are they building this web browser? Who is supposed to use it? The only argument I've heard is from people who want to support an open rendering engine, which has to be a smaller group than people who want support for weird extensions. And the Chrome-based engines are open already making the whole thing a bit moot.
The Mozilla corporation turns out not to have an interesting plan for Firefox. So cutting extension developers out from trying new things was a massive blunder that has basically doomed them to their current path - they don't know how to make an interetsing web browser and they've locked anyone else out from using their toys. Konqueror of all browsers spawned this massive ecosystem of successful spin-offs [0]. Mozilla failed to do anything useful.
Thank goodness the KDE devs were on their game, I suppose. Turns out in hindsight they were building the OSS flagship and foundation of the modern internet.
[0] https://upload.wikimedia.org/wikipedia/commons/7/74/Timeline...
> AFIK the amount of people stopped using Firefox because of XUL isn't to big, you could say a vocal minority.
The vocal minority is making the mood for the silent majority. Of course are there multiple reasons for the drop of Firefox, but public awareness is probably the strongest for this. If the laymen hear how much Firefox sucks now, instead of the praise of how secure and awesome it is, they will have no reason anymore to cope with the flaws.
The vocal minority is making the mood for the silent majority. Of course are there multiple reasons for the drop of Firefox, but public awareness is probably the strongest for this. If the laymen hear how much Firefox sucks now, instead of the praise of how secure and awesome it is, they will have no reason anymore to cope with the flaws.
That interesting niche is at the Pale Moon browser initiative and their very interesting derivatives. Pale Moon still runs XUL.
Correct, which completely disproves the idea that FF adoption is in any meaningful way driven by (the lack of) XUL support.
If that was true, we'd expect to see forks like Pale Moon be _way_ more popular.
If that was true, we'd expect to see forks like Pale Moon be _way_ more popular.
Well, i use PaleMoon. Firefox is only for sites which don't work with Palemoon.
I disagree. The XUL forks serve their purpose well, but their lack of popularity is more due to being built by a very small team of volunteers, who've taken on the thankless and gargantuan task of maintaining the aging codebases of both Firefox and XUL addons, backporting security fixes from upstream, all the while fighting against limitations imposed by Mozilla as mainstream Firefox moved on.
There's no reasonable chance that such a project could ever build a user base to register as even a blip on the market share graphs.
Some people avoid it precisely because of this doomed factor. Personally, I can't rely on nor trust that a project of that scale is able to navigate the security minefield that modern browsers are, and fix all the routinely discovered issues, let alone those that remain hidden and unreported. So choosing to use it is a conscious acknowledgement that you're sacrificing security for those other features, and very few people are willing to make that sacrifice.
There's no reasonable chance that such a project could ever build a user base to register as even a blip on the market share graphs.
Some people avoid it precisely because of this doomed factor. Personally, I can't rely on nor trust that a project of that scale is able to navigate the security minefield that modern browsers are, and fix all the routinely discovered issues, let alone those that remain hidden and unreported. So choosing to use it is a conscious acknowledgement that you're sacrificing security for those other features, and very few people are willing to make that sacrifice.
The premise in the comment that started this chain is that Firefox's declining market share is caused by a lack of XUL support.
The only way this can be true, but for Pale Moon and similar to have almost no userbase, is if the majority of people are leaving FF for lack of XUL support and going to Chrome/Safari, which makes little sense to me.
The only way this can be true, but for Pale Moon and similar to have almost no userbase, is if the majority of people are leaving FF for lack of XUL support and going to Chrome/Safari, which makes little sense to me.
People don't know about Palemoon or Seamonkey or Konqueror or other web browsers. They knew about Firefox because it evolved from Netscape -> Mozilla.
Again, this is completely irrelevant to the point that I'm making. It would be possible for people to find out about them if they actually cared about XUL support so much they quit using FF for it.
> Which is remarkable given the wide range of impressive things it could do up to 2016 that it cannot do today.
Like what?
Like what?
I might be one of the dozens of people in the world who actually shipped production software using XUL.
It's a generic admin software for recruiting companies, still has some 200 daily users.
At the time, in 2004, PrototypeJS was all the rage, and XmlHTTPRequest didn't exist yet.
XUL helped us ship a more rich user experience without extreme pain. The whole thing was even a pseudo-SPA, using iframes everywhere, which we also used to fetch extra data for some pages without navigating.
At the time, in 2004, PrototypeJS was all the rage, and XmlHTTPRequest didn't exist yet.
XUL helped us ship a more rich user experience without extreme pain. The whole thing was even a pseudo-SPA, using iframes everywhere, which we also used to fetch extra data for some pages without navigating.
XmlHTTPRequest existed, it's just that Firefox hadn't implemented it yet. IE had it since 1999.
XMLHttpRequest was available since Firefox was called Firefox[1], and it should have been at least partly functional in 2002 when Phoenix 0.1 (the predecessor to Firebird and Firefox) was released. In 2004, Firebird just got renamed to Firefox (on version 0.8) and Safari implemented XHR. Opera and Konqueror would implement it in 2005.
The main issue obstructing the use of XHR was not browser compatibility. Internet Explorer still had 95% market share, and almost nobody cared about compatibility with other browsers then. The issue was mostly about awareness, and lack of proper tooling. The term AJAX was only coined in 2005, so the technique of using XHR to reduce page refreshes and improve page responsiveness didn't even have a name. It was used here in there by savvy web developers, but it wasn't systematic.
Before 2005, very few websites were built entirely on XHR. It was out there, lurking in the shadows, but not transforming the way web was done yet. Outlook Web Access (for which XHR was developed) is an obvious mention, but the first site that got XR popular was probably Gmail Beta, in 2004. I think a lot of developers suddenly wanted to replicate it, and with the popularization of AJAX in 2005, learning resources become easier to find, libraries and frameworks got developed to make its usage easier (anybody said jQuery?) and so on.
[1] See: https://bugzilla.mozilla.org/show_bug.cgi?id=237606. Interestingly enough, this bug report was about trying to access an XPCOM component from a web page, not about an incompatibility with whatever IE was doing. IE didn't even have XPCOM after all!
The main issue obstructing the use of XHR was not browser compatibility. Internet Explorer still had 95% market share, and almost nobody cared about compatibility with other browsers then. The issue was mostly about awareness, and lack of proper tooling. The term AJAX was only coined in 2005, so the technique of using XHR to reduce page refreshes and improve page responsiveness didn't even have a name. It was used here in there by savvy web developers, but it wasn't systematic.
Before 2005, very few websites were built entirely on XHR. It was out there, lurking in the shadows, but not transforming the way web was done yet. Outlook Web Access (for which XHR was developed) is an obvious mention, but the first site that got XR popular was probably Gmail Beta, in 2004. I think a lot of developers suddenly wanted to replicate it, and with the popularization of AJAX in 2005, learning resources become easier to find, libraries and frameworks got developed to make its usage easier (anybody said jQuery?) and so on.
[1] See: https://bugzilla.mozilla.org/show_bug.cgi?id=237606. Interestingly enough, this bug report was about trying to access an XPCOM component from a web page, not about an incompatibility with whatever IE was doing. IE didn't even have XPCOM after all!
I used XHR in IE in 1999-2001 in a production web app at a well known investment bank. It was my idea to use it after stumbling across the docs got it on msdn or another developer-only resource. The docs were extremely limited so I just played until I figured it out. It was synchronous only at that time, I asynchronous calls. I wrote the Java server code to return XML I think?
Users LOVED it. I never looked back.
Users LOVED it. I never looked back.
You are, of course, correct!
I remember building an XULRunner-based OpenVPN client GUI for a customer, before there were sane web-like cross-platform UI toolkits.
Yeah, I remember having to call out to XPCOM to do stuff like HTTP requests or TCP socket communication IIRC.
It was the Electron of its time. RIP.
Yeah, I remember having to call out to XPCOM to do stuff like HTTP requests or TCP socket communication IIRC.
It was the Electron of its time. RIP.
> Firefox developers started porting components from XUL to HTML5
More specifically, Firefox's UI wasn't just ported to HTML5, but to web components. This means much of two of the three major browsers (also parts of Chrome and Chrome OS) are using web components for the UI.
Part of what enabled a move from XUL was that HTML finally got custom elements, where XUL/XBL had had custom components for a long time.
More specifically, Firefox's UI wasn't just ported to HTML5, but to web components. This means much of two of the three major browsers (also parts of Chrome and Chrome OS) are using web components for the UI.
Part of what enabled a move from XUL was that HTML finally got custom elements, where XUL/XBL had had custom components for a long time.
I don’t believe that Web Components had anything to do with it at all.
When you control the scripting environment, and would be instantiating in scripting rather than in serialised markup, Custom Elements are one of the more superfluous features of the web platform: everything you can do with them, you can do every bit as effectively without them, at no meaningful cost or cost saving.
The point where things get a little more interesting is when you introduce Shadow DOM, because then you do have genuine capabilities that can’t be expressed in other ways (though whether you want to may be another matter).
But the real kicker, in my assessment and conclusion, is that both of these features landed after the migration from XUL to HTML began. (Not all that long after, and they have since been used variously, but the moving initiatives began before they were available.)
When you control the scripting environment, and would be instantiating in scripting rather than in serialised markup, Custom Elements are one of the more superfluous features of the web platform: everything you can do with them, you can do every bit as effectively without them, at no meaningful cost or cost saving.
The point where things get a little more interesting is when you introduce Shadow DOM, because then you do have genuine capabilities that can’t be expressed in other ways (though whether you want to may be another matter).
But the real kicker, in my assessment and conclusion, is that both of these features landed after the migration from XUL to HTML began. (Not all that long after, and they have since been used variously, but the moving initiatives began before they were available.)
I worked on this project - Web Components had a lot to do with it. It's true they weren't feature complete in Firefox when we started the project (notably missing Shadow DOM) - but the first migration from late 2017 was XBL->Custom Element (https://bugzilla.mozilla.org/show_bug.cgi?id=1500626), and we used the migration project to inform performance and feature work for Web Components within Firefox.
We could have converted the bindings to JS modules (and we did plenty of that too), but Web Components were key because they allowed us to migrate in-place with near API compatibility rather than rewriting the UI. I have a post at https://briangrinstead.com/blog/firefox-webcomponents/ with more detail on that point.
We could have converted the bindings to JS modules (and we did plenty of that too), but Web Components were key because they allowed us to migrate in-place with near API compatibility rather than rewriting the UI. I have a post at https://briangrinstead.com/blog/firefox-webcomponents/ with more detail on that point.
Such a post at that time would have greatly improved people's response to the change. Instead what we usually get is a PR sanitized gobbledygook which occupies space without speaking much at all. Now a similar thing is happening with Firefox Android and their extensions. Firefox can easily run most extensions but it's hidden behind a config in a canary release of the browser. No doubt there are some good reasons for it but we simply do not know. Ultimately this is a fault common among almost every product designer. They refuse to explain their decisions fearing (perhaps justly) that they may be proven wrong. Many such cases
> Now a similar thing is happening with Firefox Android and their extensions. Firefox can easily run most extensions but it's hidden behind a config in a canary release of the browser. No doubt there are some good reasons for it but we simply do not know. Ultimately this is a fault common among almost every product designer. They refuse to explain their decisions fearing (perhaps justly) that they may be proven wrong.
There were no good reasons for Mozilla to restrict extensions on Firefox for Android. It was a stupid decision that alienated Firefox's user base on Android with no real benefits.
However, Mozilla has finally listened to the negative feedback and custom add-on collections are now available on Firefox Beta for Android:
https://www.ghacks.net/2022/10/20/firefox-beta-for-android-n...
Mozilla also said they would start working on WebExtensions on Firefox for Android this year. The goal is to have feature parity with desktop Firefox, which includes retaining the Manifest v2 features that uBlock Origin uses:
https://blog.mozilla.org/addons/2022/12/15/new-extensions-av...
While Mozilla has made numerous missteps in the past, it looks like they're finally moving in the right direction.
There were no good reasons for Mozilla to restrict extensions on Firefox for Android. It was a stupid decision that alienated Firefox's user base on Android with no real benefits.
However, Mozilla has finally listened to the negative feedback and custom add-on collections are now available on Firefox Beta for Android:
https://www.ghacks.net/2022/10/20/firefox-beta-for-android-n...
Mozilla also said they would start working on WebExtensions on Firefox for Android this year. The goal is to have feature parity with desktop Firefox, which includes retaining the Manifest v2 features that uBlock Origin uses:
https://blog.mozilla.org/addons/2022/12/15/new-extensions-av...
While Mozilla has made numerous missteps in the past, it looks like they're finally moving in the right direction.
However, Mozilla has finally listened to the negative feedback and custom add-on collections are now available on Firefox Beta for Android
Anything to avoid putting a useful feature in a stable release or making it convenient, I suppose...
Anything to avoid putting a useful feature in a stable release or making it convenient, I suppose...
The API being unfinished, meaning web extensions could fail in random, unexpected ways, sounds like a good reason to me?
No reason why it can't be hidden behind a WARNING:MAY BREAK or about:config. But they implemented it in such a roundabout manner. Anyways the issue is not the decision but rather the communication about it. Ideally a dev post about this could have satisfied a lot of people but they chose to go with the PR soup method. It's not even that these are exclusive, include a link to dev post in the soup
https://blog.mozilla.org/addons/2020/09/02/update-on-extensi... and https://blog.mozilla.org/addons/category/mobile/ ?
> We looked at add-on usage on Android, and made the decision to start by building support for add-ons in the Recommended Extensions program that were commonly installed by our mobile users. Enabling a small number of extensions in the initial rollout also enabled us to ensure a good first experience with add-ons in the new browser that are both mobile-friendly and security-reviewed.
And progress is on the MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
> We looked at add-on usage on Android, and made the decision to start by building support for add-ons in the Recommended Extensions program that were commonly installed by our mobile users. Enabling a small number of extensions in the initial rollout also enabled us to ensure a good first experience with add-ons in the new browser that are both mobile-friendly and security-reviewed.
And progress is on the MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
When you look at the entire history of how Mozilla handled the Firefox for Android "Daylight" (version 79) refresh, these excuses were not good reasons.
Versions of Firefox for Android before 79 had the same access to extensions as desktop Firefox. The entire addons.mozilla.org site was available on stable and persistently sideloading could have been enabled on beta via about:config.
Since version 79, Mozilla has reduced the thousands of available extensions to less than 20. While uBlock Origin was one of these extensions, removing the majority of Firefox for Android's tens of thousands of extensions stripped away Firefox's best competitive advantage on Android and infuriated many users. This has been the case for the last 2.5 years, and is a regression in the browser.
Mozilla introduced the onerous add-on collections workaround on only the nightly channel in version 83. However, the nightly channel is not stable enough for regular use, occasionally crashing (with no extensions installed). Forks of Firefox for Android (such as Mull) introduced the feature into stable versions with no ill effect. While extensions on Android were not able to access desktop-only features (such as containers), the user feedback showed that the extensions on addons.mozilla.org were as stable and secure on Android as they were on desktop. Mozilla provided no legitimate reason for why the stable channel of Firefox was locked down in light of this user feedback.
Mozilla ignored or rejected user-initiated requests to approve additional extensions for Android, and the total count of approved Android extensions is currently at 16, with persistent sideloading of extensions not allowed. In contrast, desktop Firefox has 108 "Recommended Extensions", 30,255 total extensions, and access to persistently sideloaded extensions (via a setting). The restrictions on Firefox for Android turned users who wanted access to non-approved extensions away to other forks and browsers that supported them, at no benefit to users who did not use these extensions. At a minimum, adding a setting to enable access to all of addons.mozilla.org would have taken little effort to satisfy users who wanted to access non-approved extensions without affecting users who did not need them.
Versions of Firefox for Android before 79 had the same access to extensions as desktop Firefox. The entire addons.mozilla.org site was available on stable and persistently sideloading could have been enabled on beta via about:config.
Since version 79, Mozilla has reduced the thousands of available extensions to less than 20. While uBlock Origin was one of these extensions, removing the majority of Firefox for Android's tens of thousands of extensions stripped away Firefox's best competitive advantage on Android and infuriated many users. This has been the case for the last 2.5 years, and is a regression in the browser.
Mozilla introduced the onerous add-on collections workaround on only the nightly channel in version 83. However, the nightly channel is not stable enough for regular use, occasionally crashing (with no extensions installed). Forks of Firefox for Android (such as Mull) introduced the feature into stable versions with no ill effect. While extensions on Android were not able to access desktop-only features (such as containers), the user feedback showed that the extensions on addons.mozilla.org were as stable and secure on Android as they were on desktop. Mozilla provided no legitimate reason for why the stable channel of Firefox was locked down in light of this user feedback.
Mozilla ignored or rejected user-initiated requests to approve additional extensions for Android, and the total count of approved Android extensions is currently at 16, with persistent sideloading of extensions not allowed. In contrast, desktop Firefox has 108 "Recommended Extensions", 30,255 total extensions, and access to persistently sideloaded extensions (via a setting). The restrictions on Firefox for Android turned users who wanted access to non-approved extensions away to other forks and browsers that supported them, at no benefit to users who did not use these extensions. At a minimum, adding a setting to enable access to all of addons.mozilla.org would have taken little effort to satisfy users who wanted to access non-approved extensions without affecting users who did not need them.
What also annoys me is they disabled about:config on the Firefox for Android Stable release..
The product designers don't realize that a lot of the backlash comes from the technically-minded audience, and that their usual approach of highlighting user benefits only further fuels distrust among that vocal community.
Discussed at the time (of the article):
Why Did Mozilla Remove XUL Add-Ons? - https://news.ycombinator.com/item?id=24231017 - Aug 2020 (336 comments)
Why Did Mozilla Remove XUL Add-Ons? - https://news.ycombinator.com/item?id=24231017 - Aug 2020 (336 comments)
I was very sad when XUL disappeared from Firefox - I had written a serial plugin in c++ via XPCOM, which had allowed us to more easily test and deal with firmware updates in the hardware we ran, and having XUL in Firefox meant for fairly quick and lightweight touchscreen applications that could be shipped to customers with very low hardware requirements, nothing like you'd need for electron today.
these were for point-of-decision kiosks, and were so easy to build and maintain, truly a great era.
these were for point-of-decision kiosks, and were so easy to build and maintain, truly a great era.
You can still use XUL based add-ons. You just can't do it in the chrome-in-spirit modern Firefox. There are plenty of great Firefox forks still maintained to this day that support XUL add-ons. And despite Mozilla's attempts to stop it users have scraped and collected together all the old addons in various archives.
I'm not saying this is a good solution for facebook/youtube/twitch/etc users that treat their browser as an OS to run applications. It's not. But if you surf with javascript disabled and tend to only use actual websites written in HTML it's still viable. (the html web still exists, it's just not as loud and attention grabbing as the megacorp javascript silos)
I'm not saying this is a good solution for facebook/youtube/twitch/etc users that treat their browser as an OS to run applications. It's not. But if you surf with javascript disabled and tend to only use actual websites written in HTML it's still viable. (the html web still exists, it's just not as loud and attention grabbing as the megacorp javascript silos)
who actually surfs with js enabled? gotta be less than 1%
You wouldn't know because none of the trackers would fire...
That is a common misconception.
There are multiple ways to track people with similar precision as common JS trackers without using JS.
When it comes to simple statistics there are even far more ways.
I would go a step further and say that JS tracking is mostly limited to a certain very small subset of people which making it likely less then 0.01%, potentially even much less then that.
Most of the web is inaccessible without JS including many of the most widely used websites and most users don't even understand why not using JS could do anything good. Or understand what JS is. Expecting any not completely irrelevant non-JS browser share is just not realistic.
There are multiple ways to track people with similar precision as common JS trackers without using JS.
When it comes to simple statistics there are even far more ways.
I would go a step further and say that JS tracking is mostly limited to a certain very small subset of people which making it likely less then 0.01%, potentially even much less then that.
Most of the web is inaccessible without JS including many of the most widely used websites and most users don't even understand why not using JS could do anything good. Or understand what JS is. Expecting any not completely irrelevant non-JS browser share is just not realistic.
This is all beyond the point which was that stats about no-JS users are almost nonexistent. You can keep saying "but there can't be many people using web without js" but they literally fly under your radar.
> There are multiple ways to track people with similar precision as common JS trackers without using JS.
And almost no one uses them.
> I would go a step further and say that JS tracking is mostly limited to a certain very small subset of people which making it likely less then 0.01%, potentially even much less then that.
I barely see a project that does anything except Google Analytics at default settings with a script tag.
> Most of the web is inaccessible without JS including many of the most widely used websites
"Most of the web" actually works. Some of the popular ones don't but Wikipedia/Google/Amazon/Facebook (to a degree) are OK. All latest front-end frameworks are built to deliver working HTML with minimal JS instead of SPAs.
> most users don't even understand why not using JS could do anything good. Or understand what JS is.
There was a time most users didn't even understand why not using IE could do anything good or understand what a browser is. Times change.
> There are multiple ways to track people with similar precision as common JS trackers without using JS.
And almost no one uses them.
> I would go a step further and say that JS tracking is mostly limited to a certain very small subset of people which making it likely less then 0.01%, potentially even much less then that.
I barely see a project that does anything except Google Analytics at default settings with a script tag.
> Most of the web is inaccessible without JS including many of the most widely used websites
"Most of the web" actually works. Some of the popular ones don't but Wikipedia/Google/Amazon/Facebook (to a degree) are OK. All latest front-end frameworks are built to deliver working HTML with minimal JS instead of SPAs.
> most users don't even understand why not using JS could do anything good. Or understand what JS is.
There was a time most users didn't even understand why not using IE could do anything good or understand what a browser is. Times change.
> Times change.
Exactly, they changed from no-js having some relevance to it basically having no relevance at all and most no-js support is legacy from the past.
Today in my experience people are less, not more, likely to disable Js.
EDIT: Also a non small part of the web today is video content, which won't work without js.
Exactly, they changed from no-js having some relevance to it basically having no relevance at all and most no-js support is legacy from the past.
Today in my experience people are less, not more, likely to disable Js.
EDIT: Also a non small part of the web today is video content, which won't work without js.
Yeah yeah, "I don't think there are many no-JS users", etc, you keep repeating this in different ways without refuting the point.
> Today in my experience
Today in my experience 99% of trackers only measure users with JS.
> Exactly, they changed from no-js having some relevance to it basically having no relevance at all and most no-js support is legacy from the past.
People learned basic technical ideas and changed from buggy insecure ways of browsing the internet (IE, activeX) and forced web engineers to change their ways (test in other browsers than IE) before. It's not even a question of "will it happen again?" because it's already happening
> EDIT: Also a non small part of the web today is video content, which won't work without js.
Maybe you are just not qualified to argue this. Videos work just as images, text or audio. Try disabling JS and opening https://en.wikipedia.org/wiki/Video for example, it works just fine. If a video doesn't load without JS it's a problem with website or browser implementation.
> Today in my experience
Today in my experience 99% of trackers only measure users with JS.
> Exactly, they changed from no-js having some relevance to it basically having no relevance at all and most no-js support is legacy from the past.
People learned basic technical ideas and changed from buggy insecure ways of browsing the internet (IE, activeX) and forced web engineers to change their ways (test in other browsers than IE) before. It's not even a question of "will it happen again?" because it's already happening
> EDIT: Also a non small part of the web today is video content, which won't work without js.
Maybe you are just not qualified to argue this. Videos work just as images, text or audio. Try disabling JS and opening https://en.wikipedia.org/wiki/Video for example, it works just fine. If a video doesn't load without JS it's a problem with website or browser implementation.
> Maybe you are just not qualified to argue this. Videos work just as images, text or audio.
no you just have no idea how most normal internet user use the internet
sure video works technically, but that's not only not enough, it's irrelevant. What matters is that it needs to work without too much friction and convenience and no-js is the opposite of that. It's a constant running into stumbling blocks again and again. Stumbling blocks most internet user can not solve by themself in just a few seconds. And in turn they will not use no-js, no matter how much anyone tells them it is more secure because it simply doesn't work for them no matter how much it's technically possible.
no you just have no idea how most normal internet user use the internet
sure video works technically, but that's not only not enough, it's irrelevant. What matters is that it needs to work without too much friction and convenience and no-js is the opposite of that. It's a constant running into stumbling blocks again and again. Stumbling blocks most internet user can not solve by themself in just a few seconds. And in turn they will not use no-js, no matter how much anyone tells them it is more secure because it simply doesn't work for them no matter how much it's technically possible.
> Today in my experience 99% of trackers only measure users with JS.
So not true. Ever hear of tracking pixels? ETag manipulation? User-Agent tracking?
> Maybe you are just not qualified to argue this. Videos work just as images, text or audio.
... ever hear of tracking pixels?
These have not been theoretical for a very long time and nowhere close to an exhaustive list. GET requests are usually loaded with parameters as well.
So not true. Ever hear of tracking pixels? ETag manipulation? User-Agent tracking?
> Maybe you are just not qualified to argue this. Videos work just as images, text or audio.
... ever hear of tracking pixels?
These have not been theoretical for a very long time and nowhere close to an exhaustive list. GET requests are usually loaded with parameters as well.
Nobody is claiming that such methods do not exist, so naming them adds nothing to this thread.
I guess I thought I was more clear in my previous comment when I said these are not theoretical.
Non-JS tracking methods are not just common and not just fallbacks. They are the standard for marketing and anti-abuse mitigations.
I'll list a couple more details that make it more familiar.
Search engines have been distributing shortened URLs and parameterized links pretty much since the beginning. Both are tokenization schemes that don't require JS and if used correctly are impossible for the user to "block".
Non-JS tracking methods are not just common and not just fallbacks. They are the standard for marketing and anti-abuse mitigations.
I'll list a couple more details that make it more familiar.
Search engines have been distributing shortened URLs and parameterized links pretty much since the beginning. Both are tokenization schemes that don't require JS and if used correctly are impossible for the user to "block".
You could probably guess it by taking a diff of server side requests between a browser initiated dest (header.png) and js initiated dest (/api/user). Yes there would be gotchas around crawlers, adblockers etc but could do for a decent first go.
Also wouldn't be generalisable to the wider internet because 'does the site even work without js' would be a huge cofounder.
Still wish I had access to traffic stats on a large enough site to play around with this.
Also wouldn't be generalisable to the wider internet because 'does the site even work without js' would be a huge cofounder.
Still wish I had access to traffic stats on a large enough site to play around with this.
You could, but 99% of websites I encounter just throw in a GA/GTM script and with statically generated sites there's no server side whatsoever.
I remember using Songbird in the late 00s, a music player built on top of XULRunner, as well as a twitter client. They're not exactly 1-to-1, but there's something funny to how Electron provides that browser-based platform for desktop apps now.
It's even mentioned in the article.
I think I tried it back then, but preferred foobar2k.
I think I tried it back then, but preferred foobar2k.
[deleted]
I remember getting a fork of it, Philips Songbird, with an MP3 player and using it for a few years on a Windows XP machine. Worked much better than iTunes, and I actually kinda miss it a lot.
I worked hard to keep my addon compatible with Songbird.
I was partial to Flock, another XUL browser. It integrated a bunch of of social media APIs of the day in interesting ways.
I remember Flock fondly. Any recall why it didn’t work out? Did Firefox’s ascendency stall out Flock?
I think it sputtered out from lack of uptake and social media public APIs dying off and social media trending towards silos and walled gardens.
It's interesting to think about what alternatives to this path could have existed.
The author makes what he thinks is a watertight argument about security, but it's a lot leakier than is made clear. Mozilla didn't actually have an extensions malware problem at any point. That's why he won't cite any actual examples, saying in the comments he's afraid of lawsuits because the extensions came from "high profile apps". High profile apps the user is choosing to install are by definition not malware, yet Mozilla allowed a bizarre authoritarian impulse to develop amongst its engineers that let them rationalize to themselves that any desktop app that extended Firefox (i.e. outside the add-ons site they controlled) was "malware" regardless of what it did or whether users actually liked it. That's a totally incorrect definition, which is why they are so squirrelly about it, any why users reject it.
Nor is the API stability argument well founded. Nothing would have stopped them introducing stable APIs they could commit to and helping extension authors migrate. They could have implemented WebExtensions as well as continuing to allow XUL extensions, which would have given the extensions that didn't need more functions stability without killing the others. Why could Google design such APIs but not Mozilla?
The real reason they didn't want to does seem to be described - designing APIs and then sticking to them is tedious and boring work. The chrome guys didn't have to do that, at least for a while. What fun!
In a parallel universe, Mozilla realized that whilst performance and security are important, they're also largely a pure function of how much you depend on engineers and thus they could never win against Chrome in that department. The only battlefield on which they could gain advantage was the field of ideas. Features were the one place their smaller engineering budget wouldn't automatically lose against Google, but clearly by this time Mozilla had run out of ideas for features users might want. XUL extensions were a valuable proving ground for features they could then later have merged into the main browser, potentially finding even just one idea that Chrome would struggle to match.
Reducing the maintenance burden could have been done in all sorts of ways, for example by using a Linux Kernel style model in which popular extensions are invited to be developed in tree where they can be activated during testing cycles and refactored atomically as the browser changes. Typescript would have made this easier, but xpcom already offered some type safety.
The author makes what he thinks is a watertight argument about security, but it's a lot leakier than is made clear. Mozilla didn't actually have an extensions malware problem at any point. That's why he won't cite any actual examples, saying in the comments he's afraid of lawsuits because the extensions came from "high profile apps". High profile apps the user is choosing to install are by definition not malware, yet Mozilla allowed a bizarre authoritarian impulse to develop amongst its engineers that let them rationalize to themselves that any desktop app that extended Firefox (i.e. outside the add-ons site they controlled) was "malware" regardless of what it did or whether users actually liked it. That's a totally incorrect definition, which is why they are so squirrelly about it, any why users reject it.
Nor is the API stability argument well founded. Nothing would have stopped them introducing stable APIs they could commit to and helping extension authors migrate. They could have implemented WebExtensions as well as continuing to allow XUL extensions, which would have given the extensions that didn't need more functions stability without killing the others. Why could Google design such APIs but not Mozilla?
The real reason they didn't want to does seem to be described - designing APIs and then sticking to them is tedious and boring work. The chrome guys didn't have to do that, at least for a while. What fun!
In a parallel universe, Mozilla realized that whilst performance and security are important, they're also largely a pure function of how much you depend on engineers and thus they could never win against Chrome in that department. The only battlefield on which they could gain advantage was the field of ideas. Features were the one place their smaller engineering budget wouldn't automatically lose against Google, but clearly by this time Mozilla had run out of ideas for features users might want. XUL extensions were a valuable proving ground for features they could then later have merged into the main browser, potentially finding even just one idea that Chrome would struggle to match.
Reducing the maintenance burden could have been done in all sorts of ways, for example by using a Linux Kernel style model in which popular extensions are invited to be developed in tree where they can be activated during testing cycles and refactored atomically as the browser changes. Typescript would have made this easier, but xpcom already offered some type safety.
I agree.
I don't doubt that XUL had severe limitations, security issues, and was a nightmare to maintain. But all of those were mostly problems for Mozilla developers to deal with. Users didn't experience them, and any security and performance issues could've been addressed without scrapping the entire framework.
But Mozilla chose to prioritize developer well-being over the needs of their users, and chase some performance and productivity metrics compared to a novel browser built by a company with enormous amount of resources to throw at it.
And years later its old user base is still salty about that decision, watching how Mozilla becomes even more irrelevant, while being in denial and celebrating their current direction. It's a sad state of affairs, and a documentary should be made once Mozilla finally shuts down.
I don't doubt that XUL had severe limitations, security issues, and was a nightmare to maintain. But all of those were mostly problems for Mozilla developers to deal with. Users didn't experience them, and any security and performance issues could've been addressed without scrapping the entire framework.
But Mozilla chose to prioritize developer well-being over the needs of their users, and chase some performance and productivity metrics compared to a novel browser built by a company with enormous amount of resources to throw at it.
And years later its old user base is still salty about that decision, watching how Mozilla becomes even more irrelevant, while being in denial and celebrating their current direction. It's a sad state of affairs, and a documentary should be made once Mozilla finally shuts down.
Sic transit gloria mundi...
XUL, WPF, XAML ...
Main characteristic of these markups is that they define not semantic but presentational DOM.
Presentational DOM is what old HTML (v.1..3) was all about: all those <FONT>s, etc. So layout has not one source of truth (CSS) but also presentational elements (<hbox>, etc). Systems with multiple sources of truth do not play well as we know - person who has two watches does not know real time.
Problem is that XUL was naively transformed into display:flex and now CSS declaration width:100px is not a source of truth either, display:flex in galaxy far, far away can change real box width in non-obvious manner.
XUL, WPF, XAML ...
Main characteristic of these markups is that they define not semantic but presentational DOM.
Presentational DOM is what old HTML (v.1..3) was all about: all those <FONT>s, etc. So layout has not one source of truth (CSS) but also presentational elements (<hbox>, etc). Systems with multiple sources of truth do not play well as we know - person who has two watches does not know real time.
Problem is that XUL was naively transformed into display:flex and now CSS declaration width:100px is not a source of truth either, display:flex in galaxy far, far away can change real box width in non-obvious manner.
How could flex work without the ability to deform anything not explicitly nailed down? You need to specify the relative sizes of things, some of those things might be rigid, and the division of how much each item is deformed is dynamic. You would need all new flexi-units like fpx, fem, f% or you could just say everything in flex is now flexi- unless you say it’s rigid and use the same units which is more sane to me.
This
a) is significantly easier to understand b) is more flexible than bunch of flexbox props and c) does not break CSS box model and d) has clear physical model, see : https://terrainformatica.com/2018/12/11/10-years-of-flexboxi...
Just try to define same thing using flexbox...
div {
width:100px;
height:100px;
margin:1fx; // all margins, horizontal and vertical
}
a) is significantly easier to understand b) is more flexible than bunch of flexbox props and c) does not break CSS box model and d) has clear physical model, see : https://terrainformatica.com/2018/12/11/10-years-of-flexboxi...
Just try to define same thing using flexbox...
XUL was great. There was this tabs extension which allowed to have multiple rows of tabs open and even more rows accessible through scrolling with the mouse wheel.
Or another one which allowed to tile pages in one browser window.
Or another one which allowed to tile pages in one browser window.
I still miss TabMixPlus in my daily browsing. Haven't found a tab manager since that can match what it did for me.
You could try TabMixPlus: https://github.com/onemen/TabMixPlus
For me moving to Chrome was a simple case of, wow, it's fast and when it dies a single tab dies not the whole browser. I lingered a bit in Firefox professionally because of FireBug but once Chrome Dev Tools got decent I switched completely.
Now Chrome stopped showing me more than n tabs when I open too many and doesn't show UI to scroll invisible ones into view. This happens on my every windows machine. Chrome feels janky nowadays for me. So I'm trying to get back to Firefox but it's a bit hard. Recently I couldn't even get Bitwarden to work in Firefox on Windows. Fortunately I managed to switch to DucDuckGo browser on Android.
Now Chrome stopped showing me more than n tabs when I open too many and doesn't show UI to scroll invisible ones into view. This happens on my every windows machine. Chrome feels janky nowadays for me. So I'm trying to get back to Firefox but it's a bit hard. Recently I couldn't even get Bitwarden to work in Firefox on Windows. Fortunately I managed to switch to DucDuckGo browser on Android.
>Recently I couldn't even get Bitwarden to work in Firefox on Windows.
That is weird - works fine on my end. What happens?
That is weird - works fine on my end. What happens?
When I try to log into bitwarden I see that something (captcha?) was blocked in the small area undee the login and password inputs.
Error message there doesn't point me out to any resource about how I could make it work.
Error message there doesn't point me out to any resource about how I could make it work.
Odd, I don't think I have ever seen a captcha when logging in. Probably worth reporting a bug: https://github.com/bitwarden/clients/issues
It’s been over a decade since I touched a Firefox addon and I still remember their ghostbusters easter-egg/joke.
Went something like:
keymaster/gatekeeper/thereisonly.xul
Went something like:
keymaster/gatekeeper/thereisonly.xul
Also explains why their in-browser debugger was called Venkman.
In a few years Chrome will be dominant and Google will be tempted to rest on its laurels, remove resources and let it stall. It wouldn’t surprise me if the only free reasonable alternative has another comeback in the cards. If it still exists by then, of course.
Being able to script buttons in my browser's toolbars is a feature I miss (circa the Jetpack era of Firefox). It greatly increased my productivity.
Doing some of this now on my Linux desktop using jgmenu ... it's not a browser though ... it's a floating data-driven start menu. Very fun.
Doing some of this now on my Linux desktop using jgmenu ... it's not a browser though ... it's a floating data-driven start menu. Very fun.
[deleted]
The removal of XUL is when Mozilla's position as an innovator and industry leader showed it had died.
Chrome is ubiquitous not because of chrome, but because chromium is the most friendly open platform to use. V8 regularly runs laps around spider monkey, and has been embedded into thousands of critical business infrastructure. V8 isolates being a big feature. Spider monkey hasn't kept up. It's Firefox only.
Chromium can result in things like electron. Firefox could have positioned themselves that way, but chose isolation. They only want to develop Firefox, and because of that they are doing a poor job.
The math doesn't work out, eventually Firefox will have to become a chromium skin, and it will be all the better for it. Google is, after all, the ones paying for Mozilla to exist outside of their yahoo deal.
Chrome is ubiquitous not because of chrome, but because chromium is the most friendly open platform to use. V8 regularly runs laps around spider monkey, and has been embedded into thousands of critical business infrastructure. V8 isolates being a big feature. Spider monkey hasn't kept up. It's Firefox only.
Chromium can result in things like electron. Firefox could have positioned themselves that way, but chose isolation. They only want to develop Firefox, and because of that they are doing a poor job.
The math doesn't work out, eventually Firefox will have to become a chromium skin, and it will be all the better for it. Google is, after all, the ones paying for Mozilla to exist outside of their yahoo deal.
>Spider monkey hasn't kept up. It's Firefox only.
That isn't true though: https://en.wikipedia.org/wiki/SpiderMonkey#Use
That isn't true though: https://en.wikipedia.org/wiki/SpiderMonkey#Use
I miss Pentadactyl
Have you given Tridactyl a shot?
Tridactyl is nowhere near as usable as Pentadactyl was, and its injection of JS/CSS in every page you visit is very, very intrusive. Sadly it's the only option that is usable for me at the moment, but I think everyone - including its devs - would agree that it can never reach the same level to Pentadactyl due to not having access to the browser's chrome.
About five years ago we had agreement in principle with Mozilla to extend the web extension API to accept keypresses from anywhere, provided that someone did the work to write that API.
We started it [1] but lost interest because we think Tridactyl works mostly fine without it (press ctrl+, anywhere to get back to Tridactyl) and I have always found more urgent things to improve.
I'd be happy to help anyone who wanted to pick it up, but a lot of the political work of persuading Mozilla that such an API would be useful would need to be restarted since most of the people we persuaded in the past have now left Mozilla.
[1]: https://github.com/tridactyl/keyboard-api/
We started it [1] but lost interest because we think Tridactyl works mostly fine without it (press ctrl+, anywhere to get back to Tridactyl) and I have always found more urgent things to improve.
I'd be happy to help anyone who wanted to pick it up, but a lot of the political work of persuading Mozilla that such an API would be useful would need to be restarted since most of the people we persuaded in the past have now left Mozilla.
[1]: https://github.com/tridactyl/keyboard-api/
I have to say, I miss Keyconfig SO badly.
I'd never heard of KeyConfig.
To save others the effort:
It was a keyboard customizer XUL extension for Firefox and Thunderbird.
http://kb.mozillazine.org/Keyconfig_extension
To save others the effort:
It was a keyboard customizer XUL extension for Firefox and Thunderbird.
http://kb.mozillazine.org/Keyconfig_extension
Keyconfig and other legacy extensions are still available for modern Firefox with a modified userChromeJS: https://github.com/xiaoxiaoflood/firefox-scripts/tree/master...
For thunderbird there is tbkeys which is the spiritual successor. I use it to implement mutt like keybindings.
There was no excuse, they should just bring xul back
https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...
People wanted a faster, more secure, multi-threaded experience.
> Note: Having read in comments that some users apparently do not care about security, let me add that being secure is a really, really important point for Mozilla and has been since the first day. Regardless of add-ons, not having security means that an exploit is eventually going to show up that will steal user’s passwords and use them to steal their bank accounts – and that exploit will get sold around and will soon show up everywhere. Firefox developers fight this threat daily by all sorts of means, including code reviews, defensive programming, crash scene investigations, several types of sandboxing, static analysis, memory-safe languages, … Consequently, for Mozilla, if a feature prevents us from achieving great security, we always pick security over features.
You should read the link.
People wanted a faster, more secure, multi-threaded experience.
> Note: Having read in comments that some users apparently do not care about security, let me add that being secure is a really, really important point for Mozilla and has been since the first day. Regardless of add-ons, not having security means that an exploit is eventually going to show up that will steal user’s passwords and use them to steal their bank accounts – and that exploit will get sold around and will soon show up everywhere. Firefox developers fight this threat daily by all sorts of means, including code reviews, defensive programming, crash scene investigations, several types of sandboxing, static analysis, memory-safe languages, … Consequently, for Mozilla, if a feature prevents us from achieving great security, we always pick security over features.
You should read the link.
I did. The security argument is a poor one- tab managers are way more "secure" than the millions of chrome extensions that require total control of all websites you browse to. The multi-threaded and faster experience is just a matter of redesign. If UI people followed Linus's adage of never breaking compability with APIs we'd all be happier
When basically whole implementation is API (which is the case for XUL), you can't really change anything to never break it. Which is what happened - Firefox stagnated, yet managed to break extensions with every minor release.
The XUL addon system essentially allowed addons and official components alike to monkey patch any aspect implemented in XUL and indeed each other. The potential for interaction between them is therefore unlimited. When you say that its "just a matter of redesign" you are saying that if only infinite resources could be expended to avoid you never having to change anything at all the world could be a grand place. What you are failing to understand is that the browser is being secured first and foremost not against extension developers but against malicious actors. If the entire way the browser interacts is it self subject to monkey patching its infinitely harder and perhaps impossible to properly secure the single most exposed application vs the outside world.
Ideally the functionality once implemented as monkey patching can be provided by a defined interface with the addon system and indeed this is exactly what one sees today with most broadly useful extensions ported.
Incidentally if you want to analogize Firefox vs Linux the interface that is not supposed to break is the interaction with the web itself to the degree that this is possible. Linux actually makes external out of tree addons which touch let alone modify the kernel break/update themselves constantly. Linus would never have been stupid enough to commit to something like XUL for the kernel wherein he himself would be responsible for keeping thousands of monkey patching addons working while trying to evolve the kernel.
Ideally the functionality once implemented as monkey patching can be provided by a defined interface with the addon system and indeed this is exactly what one sees today with most broadly useful extensions ported.
Incidentally if you want to analogize Firefox vs Linux the interface that is not supposed to break is the interaction with the web itself to the degree that this is possible. Linux actually makes external out of tree addons which touch let alone modify the kernel break/update themselves constantly. Linus would never have been stupid enough to commit to something like XUL for the kernel wherein he himself would be responsible for keeping thousands of monkey patching addons working while trying to evolve the kernel.
Firefox Android has been awful for a while now. You cant sideload extesions on Android for at least two years now, with the only workaround being use an older Firefox:
https://github.com/mozilla-mobile/fenix/issues/20736
then they close the issue and move to bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1796184
https://github.com/mozilla-mobile/fenix/issues/20736
then they close the issue and move to bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1796184
This has nothing to do with the XUL addons discussed in the article.
But you can run Firefox Nightly and use a custom extensions list. This is how I have all my regular extensions running great on Android.
that requires registration on AMO. I should not have to do that to install an extension that I WROTE
Mozilla accepted Google's framing on what a web browser should be, and ended up in a world where it only makes sense to use chromium-based browsers since they better implement that vision. Firefox was always going to be a niche browser once Google got serious, but at least it could have been an interesting niche. Possibly it could be compared to Emacs - some people just love it because it was that customisable but it doesn't get a lot of love in the mainstream.
Now it is just unimpressive. Which is remarkable given the wide range of impressive things it could do up to 2016 that it cannot do today.
[0] https://gs.statcounter.com/browser-market-share/all/worldwid...