Why did Mozilla remove XUL add-ons? (2020)
yoric.github.io
yoric.github.io
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...
If that was true, we'd expect to see forks like Pale Moon be _way_ more popular.
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 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
How do you know?
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 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.
Like what?
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.
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!
Users LOVED it. I never looked back.
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.
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.
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.)
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.
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.
Anything to avoid putting a useful feature in a stable release or making it convenient, I suppose...
> 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...
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.
Why Did Mozilla Remove XUL Add-Ons? - https://news.ycombinator.com/item?id=24231017 - Aug 2020 (336 comments)
these were for point-of-decision kiosks, and were so easy to build and maintain, truly a great era.
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)
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.
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.
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.
> 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.
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.
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".
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.
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.
I think I tried it back then, but preferred foobar2k.
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 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.
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.
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...
Or another one which allowed to tile pages in one browser window.
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.
That is weird - works fine on my end. What happens?
Error message there doesn't point me out to any resource about how I could make it work.
Went something like:
keymaster/gatekeeper/thereisonly.xul
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.
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.
That isn't true though: https://en.wikipedia.org/wiki/SpiderMonkey#Use
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.
To save others the effort:
It was a keyboard customizer XUL extension for Firefox and Thunderbird.
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.
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.
https://github.com/mozilla-mobile/fenix/issues/20736
then they close the issue and move to bugzilla: