> I was very surprised to see that, years after it happened, some community members still felt hurt by this choice.
Actually, it shouldn’t be surprising at all since people lost a lot of useful functionality that still do not have replacements today. Users were not stuck on XUL as a technology. They cared about functionality and power user functionality!
I’m using mainline Firefox and not some fork that still supports XUL addons, but I still miss not having good replacements for:†
* Tab Mix Plus (I haven’t seen any replacement for this; and if you haven’t used this in the XUL world, you wouldn’t know the value of it)
* Lazarus (form saver)
* Session Manager (no, other session saving extensions still feel iffy to me)
For reasons I haven’t delved into, these extensions cannot live in a WebExtensions world today. So yes, I’m one of the people hurt by the choice not of removing XUL, but not providing alternatives even several years later.
> The main drawback is, of course, that WebExtensions do not give add-on developers as much power as the promiscuous extension mechanism. I hope that all the power that add-on developers need can eventually be added to WebExtensions API but that’s something that takes engineering power, a critical resource that we’re sorely lacking.
I don’t have a lot of hope since years have passed with progress in making some more addons work with WebExtentions but not really close to being there for other addons. Though the Firefox team has said it’s currently not planning to implement Manifest V3, if and when it does (and depending on how it does), that could potentially make uBlock Origin obsolete. That would be a much larger blow to the users.
†: Please let me know if you have suggestions for great replacements for the first two extensions.
I'll agree this is all true for power users but I think that catering to that small number of power users at the expense of having a faster, more stable, more secure browser earlier was a major mistake.
I loved Tab Mix Plus too and yes, there are some things you still can’t do in WebExtensions that you could do before. And that sucks. But I stopped using Firefox despite those options because it was so slow and unstable, especially on the Mac. By the time it got better, it was not only too late, but Chrome had extensions.
Catering to the loyalists is what killed Firefox. What’s more important to normal users is speed, not Tab Mix Plus.
I guess the issue is a different view of what Firefox should be; I feel that many people would be satisfied if Firefox was just a small(ish) browser catering to power users. There's nothing wrong with that: power users are users too (and there are more of them than many seem to think), and I feel that many people are somewhat frustrated that all software seems designed with only my grandmother in mind. This is an issue that extends far beyond XUL by the way.
> if Firefox was just a small(ish) browser catering to power users. There's nothing wrong with that
Except that it couldn't work in today's world, as more and more web sites would stop working in Firefox. Firefox needs significant market share to survive with an independent browser engine. Having an independent engine is key to achieving Mozilla's mission: https://www.mozilla.org/en-US/mission/
You can build a browser focused on power users if you don't need to worry about the engine. Perhaps you want to take a look at Vivaldi?
When you have a browser that is USED by programmers, the programmers will know that their own site is bad. Problems started when it stopped being a browser for programmers and power users.
They were the ones marketing it. Mozilla cut the branch on which they were sitting and is now shocked that they lose maretshare.
> I feel that many people would be satisfied if Firefox was just a small(ish) browser catering to power users.
There's no way to do that in today's environment. Browser development is extremely expensive (there's only 3 companies in the world developing competitive browser engines) so you need money. For Firefox, the only way to get serious cash is to have serious marketshare.
And in reality there isn't that many "power users". I mean, even a lot of developers (like me) use barely any extensions and in any case prefer more speed than more extensibility.
Browser development is not that expensive. Developing of Web-Engines is the dark part that sucks all the money.
> For Firefox, the only way to get serious cash is to have serious marketshare.
Not true. That's only valid if your single income is marketshare-based. Mozilla for some unknown reasons hasn't made any serious attempts in the last 15+ years to get any alternative income, instead it was satisfied with being feeding on google and yahoo, while wasting money on some obvious dead projects.
> Browser development is not that expensive. Developing of Web-Engines is the dark part that sucks all the money.
Of course, but then there's enough Chromium skins, no?
Without independent browser engine you have no clout in defining and ratifying standard (as MS recently found out) which means giving Google full control.
> Mozilla for some unknown reasons hasn't made any serious attempts in the last 15+ years to get any alternative income, instead it was satisfied with being feeding on google and yahoo, while wasting money on some obvious dead projects.
They had some feeble attempts which largely failed.
Mozilla's main expertise is still browser technology based and it is probably difficult to monetize it.
> Most of them are more than skins. A browser is the interface and whole workflow, not just the way the website is displayed.
The user interface is just minor part of the browser.
Mozilla's mission is to "free the web". Something like that can't be done with slightly sleeker UI on top of monopolistic rendering engine. You need to have an influence on all levels.
> as MS recently found out
I've read it this week in some interview with the FF developers that ever since MS gave up on homegrown Edge engine and adopted Chromium/Blink their voice on the standards committee is weak and lacks clout.
No wonder. It's google who keeps strict control over chromium/blink. MS can discuss, propose, even send PRs, but it's google who will decide what gets in and what doesn't.
> They had no SERIOUS attempt. Well until now at least. They did some half-assed with pocket and now VPN-reselling, but never touched real business.
Well yeah. But it just sounds a bit simplistic to say "just earn that $500 million profits somewhere so you can sponsor your side project Firefox".
> Mozilla's mission is to "free the web". Something like that can't be done with slightly sleeker UI on top of monopolistic rendering engine. You need to have an influence on all levels.
That depends on behaviour.
> I've read it this week in some interview with the FF developers that ever since MS gave up on homegrown Edge engine and adopted Chromium/Blink their voice on the standards committee is weak and lacks clout.
As if they had much to say before...
But that's the point, your influence depends on what you do and who is backing you. Chrome-Edge is just too small and Microsoft is not doing much to build their influence at the moment.
> Well yeah. But it just sounds a bit simplistic to say "just earn that $500 million profits somewhere so you can sponsor your side project Firefox".
If you have a budget of some hundred million dollars and a very big and enthuastic community, then it's very easy to make money. Even having enough money at all can make you money, though this might be ruled out for Mozilla because of their legal status.
> If you have a budget of some hundred million dollars and a very big and enthuastic community, then it's very easy to make money. Even having enough money at all can make you money, though this might be ruled out for Mozilla because of their legal status.
Do you have ideas that can help Mozilla make money? Preferably without abandoning Firefox on the way?
Plenty have been voiced over the last decade. The problem is that none of the observations are ever received in earnest. Particularly starting in the Kovacs years and onwards, MoCo folks have adopted a default stance that if you're not within the figurative walls of @mozilla.com, then there's something you just don't understand as well as the anointed ones do. Meanwhile, none of the moves that the better-knowers have made have ever panned out. And in any discussion that does occur, there are all sorts of rhetorical tricks and intellectually dishonest maneuvers that are brought out to shut the conversation down. The Corporation's insistence on its own competence at this point is a lot like the "I have people skills!" scene from Office Space, only it's not a comedy and just depressing.
There's the separate matter, which is that Mozilla's problem isn't even a lack of money. Mozilla has money (and will continue to have money for at least some time). Mozilla's problem is its profligate spending and that it has chosen for itself a set of decisionmakers with Netscape-levels of ineptitude who can't be avoided.
If course correction is even possible at this point—and it's probably not—then the question is, who are the Hewitts and Blake Rosses and Ben Goodgers in 2020? Has Mozilla leadership even fostered an environment where those types can thrive? (Spoiler alert: the answer is no.)
I'm not OP, (and people at Mozilla have probably already considered this), but why doesn't Mozilla try a far more aggressive Wikipedia-like donation campaign?
Admittedly:
1. Wikipedia has more "users" than Firefox.
2. Despite this, the donations Wikimedia receives are only about a fifth of Mozilla's budget.
However, people use their browser far more than they use any single website and hence might be more willing to donate more to Mozilla. (For example, I love Wikipedia, but I've gotten even more value from Firefox.)
Overall, this would be unlikely to cover all of Mozilla's expenses, but I'd also be surprised if donations (after such a campaign) would be less than 10% of current revenue; in any case it'd be a valuable source of diversification.
It's possible that the legal relation between the Foundation and the Corporation doesn't make this possible.
Encyclopedia Britannica[0] isn't free ("libre"), but it is now free (gratis). Arguably, being libre isn't quite as indispensable in the case of cultural/educational works as it is for software.
Doesn't the same also partially hold for Firefox and Chrome, though?
They wouldn't start charging for Chrome, as that's not their business model, but they might move part of their development out of (open source) Chromium and into (closed source) Chrome or further curtail extensions (e.g. adblockers) etc.
Google has done that with Android, moving more APIs and features from the open-source AOSP core to the closed-source Google Play Services library. Google can then control which Android partners get permission to ship Google Play Services for a full-featured Android experience.
As more browsers move to a Chromium base, Google might have a similar push to move more of Google's value-add out of the open-source Chromium core to the closed-source Chrome product.
No. Firefox vs Chrome is a completely different comparison than Wikipedia vs Encyclopedia Britannica.
The first two are browsers; software, the second two are stores of knowledge.
Browsers have been free for the longest time now, they are a commodity; the 'for pay' browser market died a long time ago. Possibly that was a mistake but that's where we are now and the parties that supply browers (Mozilla, Apple, Microsoft, Google to name the bulk) all try to win marketshare because they benefit from having more users. Putting up a barrier will automatically play into the hands of the opponents.
Wikipedia is a free and much larger alternative to EB, which historically was very expensive. If Wikipedia goes away there is no longer any incentive for EB to have a free tier, which is the one thing they can do to erode support for Wikipedia a little bit.
I'm not disagreeing that (in these scenarios) EB would probably become paid-for, while Chrome never would. I'm just arguing that Chrome would become even more privacy- and user-unfriendly, which is the approximate equivalent of EB putting up paywalls. (Is paying with your attention and privacy better or worse than paying directly with money?)
Apple would continue offering a relatively privacy-friendly alternative — but would require you to switch OS to use it; Microsoft might fork Chromium, but I fear that they'd only pay lip-service to privacy.
Obviously these analyses are complicated by the fact that in both cases the forces that helped create Wikipedia/Firefox wouldn't disappear. If Wikimedia died, then people would put up their Wikipedia dumps online in their own MediaWiki instances. If Mozilla died, then people would either try to keep Firefox alive or try to maintain a set of privacy patches on Chromium. How successful they'd be is another matter...
The original design goal of Firefox was to be a "90/10" browser (relative to the old Mozilla suite). e.g. 90% of the people only need 10% of the features. Catering to power users was never the goal of Firefox and they lost users to Chrome when they did. What people want is a browser that loads webpages quickly and doesn't use a lot of system resources doing so.
These "most people only use 10% of the features, so we can drop the rest" ideas are just soo stupid & can quickly kill otherwise good projects.
And it's not just about chasing away power users, who are about the only advocates and marketing you have. Its mainly about the 10% being different for every user, effectively covering the full feature matrix!
Yet that seems to be precisely who they're targeting.
The only benefit Firefox now has over Chrome is a vague political notion of not using Google-made software, something that there isn't enough call for in the real world to drive significant marketshare. Their real differentiation was sacrificed on the altar of ease of development, and now what we're left with is an also-ran, in multiple meanings of that term.
Worse, an also-ran that's doing increasingly arational things, almost as if they're wildly groping about for the mythical marketshare.
Well, perhaps not the only thing: Tree Style Tabs opens in a sidebar in Firefox (and with user CSS, can be made to auto-expand), while in Chrome it opens in a separate window.
Well, Mozilla included email, chat, and whatnot. Regardless of what the goals were, it did cater to power users and clearly many people don't want the direction Firefox went in.
> and clearly many people don't want the direction Firefox went in.
A majority? I doubt it. I think it’s an extremely vocal minority that don’t care about the slowness of their browser (pre-e10s, pre-quantum), about things breaking (XUL extensions) or about UI features for the broad masses.
I’d bet money that FF’s 25% in Germany would be far closer to US numbers if they stayed where those vocal people want them.
All I'm saying is that based on my observations people's views on what Firefox should or should not be are different, and that this explains why people are still "angry" about the extensions breaking and such. I'm not having an argument with anyone.
I still miss the old Opera, including the built-in email client I used. So yeah, I agree.
Honestly, Opera is one of the best pieces of software I've ever used. It had tons of features and customizability without being slow or feeling "bloated". I never quite understood why it failed to gain marketshare 10 years ago while Firefox did.
Strongly disagree - I think the reason Firefox market share is in a tailspin is because once they "rationalized" the codebase by getting rid of power features - there was no moat around them to keep even simple upstarts like Edge away. Programmers often make the mistake of classifying all complexity as cruft - when much of that are use cases accumulated over time that reflect your competitive advantage - one that any competitor has to overcome. The more Firefox streamlines the more they will cede ground to better funded alternatives.
Firefox’s market share started declining when Google ran huge ad campaigns for Chrome and made some of the most popular sites on the web promote Chrome and, in the case of YouTube, run better on it. Microsoft Edge didn’t affect Firefox much, and fared equally poorly against that juggernaut.
Any theory which talks about niche features without accounting for that push is unlikely to be right.
Marketing gives you leg up, but at the end of the day, a product's merits have to live up to it. Both IE and Safari had an even bigger advantage than marketing by being built-in to their respective platforms, and both have lost marketshare to Chrome.
I'll say pointblank I don't know what people see in Chrome, but they clearly see something in it. To me today, Safari, Firefox, and Chrome are essentially identical, which is a bad spot to be in for everyone except the market leader, because there's no incentive to switch.
UPDATE: There's a stronger case regarding Google sabotaging Firefox, but I don't think that accounts for the magnitude of the switch, here's a detail of the accusation[0]:
> A Mozilla Program Manager named Chris Peterson accused Google of making Youtube performance slower on the Firefox explorer in July 2018. Peterson alleged that Google was aware that both Firefox and Edge, Microsoft’s browser, were performing better with regard to loading the popular video sharing platform YouTube and decided to switch to a Javascript library which was incompatible with Firefox.
Google Chrome became the dominant browser around 2012, after being released in 2008. That's an astronomically fast takeover, if there were any shenanigans that accounted for it, they'd have to be quite aggressive (and therefore discussed more at that time).
Back in the day, Chrome was faster — almost as fast as Safari to launch and faster when executing heavy sites. When it took IE and Firefox longer to load, installing Chrome was something which had an immediate benefit and Google's heavy promotion of it meant that most people gave it a try.
These days, I agree that the main problem is that any modern browser is good enough that people don't feel a huge pressure to switch. I prefer Firefox's developer tools but that's not exactly a mainstream need. The most obvious angle would be something about ad blocking and privacy where Google has significant financial incentives not to follow but I' m not sure how much of an audience that could add up to and it will definitely get hostility if effective.
My grandmother used Tax Mix Plus several years ago. I personally found it a bit laborious, but she liked organising her reading. That was such a wonderful extension.
People on HN make the mistake of assuming that the mythical 'average' user will not use such features. And convincing them otherwise is so difficult. The folks who love your product will plumb every depth of it. Not everything needs to be dumbed down to the dirt.
If normal users cared about speed they can go and use Chrome. The framing in many of the comments here seems to be that there is 1 ideal that all web browsers should be working towards; and it is represented by Google Chrome. That isn't really the case, there are multiple interpretations. It is very annoying that Firefox chose the path of being Chrome-but-worse. All the people who want Chrome are using it - or chromium - and they don't need Firefox trying to implement the same thing but in red.
Firefox has lost substantial features over the years - Chatzilla for example was a great little add-on. It is quite a bold strategy to write a blog post saying "we stripped out a bunch of features, but trust me you didn't want them". Even if it is true there doesn't seem to be the level of regret here that is appropriate for trashing an ecosystem that has never recovered.
> I think that catering to that small number of power users at the expense of having a faster, more stable, more secure browser earlier was a major mistake.
Catering to power users is the only reason Firefox ever had market share in the first place! Normal users do not install their own browsers. Normal users do not care about their browser. They barely even know what a browser is, other than it's the thing they use to get on the Internet.
Every bit of Mozilla's original market share came from power users wanting a browser with more features and power than Internet Explorer. And once the power users fell in love with it, they evangelized it relentlessly to their friends and family. There were campaigns for power users to go install it on grandma's computer. This is the only way Firefox ever got on a normal user's computer. (This was also the only way Firefox got headway in enterprise environments, though it would have made a lot more if Mozilla had listened to power users and system admins and added the group policy and installation options they asked for.)
Chrome crushed Firefox because it was a decent, fast browser and because of the massive marketing budget. Chrome was and is pushed hard on the biggest web properties on the world - you get notifications on Google and YouTube if you use anything other than Chrome. Various other installers also installed Chrome, unless you unchecked a box. There were TV commercials. It was the default browser on Google platforms from phones to Chromebooks. That's why Chrome won.
When Firefox killed feature after feature that catered to power users, power users cared less and less about evangelization, and some of them switched to Chrome because Firefox was becoming increasingly Chrome-like, Chrome dev tools were evidently pretty good, and many people perceived Chrome to be faster. I still use Firefox, but I honestly don't see any reason to other than ideological reasons, which are becoming increasingly tenuous and not really a winning argument even for power users.
This is why Firefox usage will continue to decline. It doesn’t matter how much faster Firefox becomes. It doesn’t matter how much easier Firefox development gets. Mozilla alienated their core user base, they aren’t coming back, and normal users are never going to start installing niche browsers that aren’t pushed hard by multi billion dollar companies. Mozilla has no path forward. They’ve screwed up irrevocably and the best they can hope for is to manage the decline and cling to their remaining user base. Unfortunately, it doesn’t look like they’re going to be able to manage even that.
uBlock Origin is important enough to Mozilla that it's featured prominently on the add-ons pages, it was the first add-on made to work on the new Firefox for Android ("make uBlock work" was its own milestone item), and Mozilla developers have actually contributed design work back to the project. Couple this with the positioning win of having uncrippled blocking compared to Chrome, and you can rest assured that Firefox won't break uBO.
Well, that is a single addons and only one of 9 currenly allowed on Android Firefox (!!). All the other addons not on the list - bad luck!
Its nice they help an addon or two, but does not help if they neglect the overall addon API & don't even let you install other addons not on their cherry picked list, even if they would work just fine!
> Well, that is a single addons and only one of 9 currenly allowed on Android Firefox (!!). All the other addons not on the list - bad luck!
What are you talking about? When I go to the store on Firefox for Android right now, it shows me a list of 11 "featured" extensions (so 9 is already wrong). To test whether that list is exhaustive, I searched for an extension not in the list (Old Reddit Redirect). I successfully installed it and confirmed that it works. So as far as I can see, both of your claims are completely wrong.
Are you sure you are running the new Fenix based Firefox (~v79) and not the old Fennec based one (v68) ?
They are rolling the update in vawes abd not all countries are yet affected. But you can still try Fenix based Firefox by installing the Beta ir Nigtly versions
Mozilla has replaced the existing Android app, Fennec, with Fenix. It has not rolled out to all users and regions yet. So some users have yet to get or even see the update.
Fenix uses a whitelist-only model for extensions, and had only around 9, last I checked. Based on some github issue comments, it seems like they'd prefer to stay with a whitelist approach for the foreseeable future.
If your extensions are important to you, you'll need to disable auto-updates for Firefox in the Play store, and avoid using 'update all' and similar - that is, if your extensions aren't on the list.
A version of the old app is available through F-Droid, but it purports to de-mozilla-fy the browser, so I presume sync and other things may not work the same.
A couple more info points - yep, they indeed have a list of addons and if the addon is not on the list, you just can't run it, full stop. Even if no one actually tried if it is broken.
I know this as a fact as someone posted a patched build with a custom list covering many more addons. I installed that and tried two addons from that list I use on desktop Firefox. One did not work (ImTranslator), but the other run just fine (Furiganaize) as on desktop. So Firefox developpers are blocking user from using perfectly working addons as they can't be bothered to add them to their fancy list of allowed addons.
About Fennec from F-Droid
I have been using it since Mozilla broke the perfectly working Firefox install on my Android tablet with the quarter baked Fenic based release and so far I have not found anything missing even if it is supposedly cleaned up from non-free parts. But I don't use Firefox sync, so I can't comment on that.
BTW, Fenix based Firefox build is being worked on for F-Droid as well (they had to cut out all the non-free stuff Mozilla puts into a normal Firefox binary, reportedly a lot more than for Fennec) so if Fenix becomes usable one day, one can get it from a source that will not stealthily replace it by something broken.
I hope the new one is less of a disappointment. The current one can't even do basic stuff like search through bookmarks/history, has no awareness of various things like tags in bookmarks, overall just still missing such a vast amount of functionality from desktop.
They also made lots of promises about supporting these popular addons in WebExt era in particular, you should still be able to find plenty of meta-bugs about them on Bugzilla [1].
Of course, most of them never happen, and people are disappointed.
Not sure what this one used to provide, but I rely a lot on Form History Control [1] to save my input before the browser crashes (which it tends to do every ~10 minutes these days) and stupid websites. I have done so for years, probably even when XUL was still a thing.
I use panorama Tabgroups as well as treestyletabs, but they have trouble coping with my 600+ tabs workflow. I think I might write my own with a graphical tree representation on a pinned tab, sort of a mindmap with tabs inside, comments, notes, etc. As this is how I would like to use my browser.
Why is your browser crashing every ten minutes? I can't tell you the last time that the desktop versions of Chrome, Firefox, or Safari crashed for me. That seems like a huge productivity issue if you have to restart the browser frequently.
It looks related to Wayland (sway). This behaviour has cropped up recently. Might be a combination of:
* Having a relatively big number of tabs (~600 in multiple tab groups)
* Having a lot of extensions
* Using sway/wayland
* Combination of the following environment variables: MOZ_ENABLE_WAYLAND=1 MOZ_WEBRENDER=1 MOZ_USE_XINPUT2=1
It used to work fine, until something broke a few weeks ago, maybe in a sway/mesa/firefox update (running ArchLinux). This was way worse when autoscroll was enabled, so I disabled it as there is a bugreport for that.
I'm on holidays, so the browser is more of a productivity sink than something else, at times. Usually I don't mind much, and might restart it or leave it. Plus, 10 minutes is kind of an overstatement (it sometimes happens faster, but last three crashes took 23, 17 and 18 minutes respectively).
I'm living on the bleeding edge, so that kind of stuff happens. I's recently gotten way worse with Qt apps as well, so I would tend to blame sway. But running it as is is a good way to find patterns that might help resolve the issues once reported. I've said a few words in #sway, but didn't get an answer.
Don't worry, I could probably change my configuration in a few seconds if I needed more stability in a pinch (use another compositor, maybe another browser): I've launched a few Qt applications with -platform xcb recently.
I'm getting errors ranging from [GFX1-]: Receive IPC close with reason=AbnormalShutdown to Gdk-Message: Error reading events from display: broken pipe
If you have time, please file a bug with some links from your about:crashes. At least for Firefox, 600 tabs really isn't that many. (At least for us many-tab people; the more common "...but why would you ever have more than half a dozen tabs open, ever?!!" people will look at me in horror.)
I don't know for sure, but those error messages look more like what happens when one process (eg the renderer) crashes and severs its connections with others. They're probably unrelated to the actual problem.
It may be that what you're running into is a side effect of forcing WebRender on blacklisted hardware? I could imagine it starting to use a new API that's buggy in your driver. </wild-handwaving>.
> * Having a relatively big number of tabs (~600 in multiple tab groups)
I have found this extension[0] useful, for saving my machine when I leave too many tabs open.
Just make sure to whitelist things you don't want unloaded. Like infinite-scroll webpages.
Hmm. I was using a surprisingly similar setup (Arch, Sway, and Firefox) and never had those issues, but I think I was using Firefox with XWayland instead of those environment variables. I'm glad it's not a huge pain for you.
I use firefox under sway with MOZ_ENABLE_WAYLAND=1 MOZ_WEBRENDER=1 and 100-ish tabs and 5-10 extensions and have not experienced crashes. Not the exact same env, but somewhat similar.
Possible replacements for Tab Mix Plus: Obviously there's no drop-in replacement for everything. Even with that aside, it's hard to make recommendations because it had so many features and probably a few were especially important to you and they might differ from the ones that were important to me.
For me, the number one feature originally was to force absolutely all popups to appear in tabs, not windows. This is actually just a built-in option now (maybe it was all along?) [1]
I used to use a feature where you could hold down the right mouse button and use the scroll wheel to switch tabs - I can't remember now whether that was provided by Tab Mix Plus or FireGestures. Anyway, now it's in FireGestures' successor, Foxy Gestures [2].
But the main recommendation is Tree Style Tab [3] (plus its own extensions [4] e.g. I use TST mouse wheel, and there seems to be a tab colouring one if that's your cup of tea). The key thing is that TST draws the tabs itself so it can make any manipulations it likes to them, which it can't do with the original tab bar in new extensions (you can hide the original tab bar [5] to avoid confusing and wasteful duplication).
I realise that laying your tabs out in a totally different way is quite a big change but it's actually an amazing change by itself. It's a much more logical way to layout tabs, and you can see more tabs at once (without resorting to multiple rows - yuck!). Once you get used to it, using a linear tab bar seems ridiculous in comparison. Plus extra vertical screen space is useful and horizontal space is typically just wasted. I recommend playing with its options a bit though; I find its default behaviour (collapsing trees automatically when you switch to another one) a bit frustrating.
I certainly care about having proper multiprocess support, and that was an important reason for letting go of XUL. Given the choice, I'd chose what we have now.
You could consider downloading the source for firefox, modifying the UI and building. Swap patches with other people and you have your "promiscuous" extensions.
... and then maintain it all yourself. Depending on what your patches do you might need to be a skilled systems level polyglot programmer. And make sure not to fall behind tracking mainline because there's new zero days all the time! Related, I sure hope you're not trying to compile on a laptop with limited RAM.
If you go in with the intention of writing an extension rather than a general case fork then it becomes a bit easier. You know from the start that you will rebase on top of upstream over and over again, and you should write code taking that into account. Minimal changes to existing code, ideally put your code in separate files and make single line changes to existing code to install hooks. Consider what code and interfaces are stable and what changes a lot.
Sort of? But the amount of effort required is much higher. Source patches require having a full dev environment, it takes much longer to build the entire browser and you also have to take on responsibility for rebasing onto upstream, dealing with security releases for the browser itself _and_ every one of the patches, and running an update infrastructure.
Extensions from other people (which is 90%+ of them even for extension developers) just need to be loaded, and your own extensions only need a text editor and something that can make zip files.
Maintaining Firefox build and update environments is a multiple-employee full-time job at Mozilla, and that's before you've even started modifying anything. It's just too much to expect an end user to do this (and even extension developers are end users most of the time).
I had written multiple XUL based addons that I used for personal productivity. When Firefox moved away from XUL/XPCom I think they removed not just an implementation (which I admit had many warts) but also the alternate vision of the Browser being extensible by end users who were almost on an equal footing with Browser developers. As a developer I can live with, support and cheer for a worse implementation of a better idea, but when you give up on that idea you rob me of any reasons I could use to support or evangelise for you.
It boils down to a simple question - does Firefox intend to go after power users in ways Chrome will not or cannot? The answer to this question used to be very clear to me in the first decade, now I think the answer is no. Even the Rust based oxidation efforts seemed limited to coming up with better implementation of the same primitives that Chrome offers, I didnt see anything about offering fundamentally different tradeoffs / choices.
If Firefox course corrects to going back to power users, I will be the first one to cheer them on. The vision for firefox has to be to reduce the gap between what browser developers can do and what end users can do.
I think your comment is a much more salient criticism.
In many ways, webExtensions could be a more accessible system than XUL addons if there was a serious effort to give the end-user more tools to use them. I honestly really like the overall architecture of webExtensions, and I like the idea of having more core code in modern Javascript. But there's a lot of weirdness around the ecosystem itself that makes building extensions into a chore.
There's a theoretical set of changes Firefox could make that would turn webExtensions into an extremely accessible, powerful user-facing feature for on-the-fly customizing and inspecting what their browser was doing. And I don't think it would need to be that inherently less secure.
It would need to approach security differently, but I feel like many of these are solvable problems, and many of the changes required (better sandboxing, active tab permissions) are stuff we want for extensions today anyway.
Some of the changes that came out of dropping XUL are really good. A lot of Firefox's styling is handled through CSS now. That should be a huge accessibility win for new users, and it should provide a nice gateway for new users to think more about moving on to making their own websites using the same technology. Except... userChrome.css is hidden in a config directory somewhere and not loaded by default[0]. They built a really nice way for users to quickly add minor styling customizations, and then they hid it from end users.
Sure - I can see that if we do arrive at a future where all of Firefox chrome is implemented via a HTML/CSS itself and it sits on top of a standardized core that exposes well documented APIs (which both end users and Firefox developers) can use for feature development - then yes we will be back to the world where someone outside Mozilla could build something like Komodo IDE on top of Mozilla tech.
One question I have as a user - what is an acceptable grace period for coming up with an equivalent replacement when you take an API away? Even the CSS styling not being loaded by default that you pointed out suggests that Firefox devs appear to view extensibility as something that they have to support cautiously and grudgingly. There is a chicken and egg problem here - if you make it harder to develop, build and ship non trivial extensions to end users then only a tiny fraction of users will use them. Then you will use the lack of usage of these extensibility features to deprioritize the development efforts that go into them.
I would really like someone to take on the task of building a "Workstation" browser - built for power users.
> There is a chicken and egg problem here - if you make it harder to develop, build and ship non trivial extensions to end users then only a tiny fraction of users will use them.
This is a really good point.
> what is an acceptable grace period for coming up with an equivalent replacement when you take an API away?
I really don't know.
I am frustrated with the current state of extensions in Firefox, even as I acknowledge that the situation in Firefox is still way better than it is in browsers like Chrome or Safari, and even as I remain hopeful that the Firefox extension ecosystem could be really good. I am sympathetic to the argument that it's an engineering resources problem. But, that also makes me really nervous about the Mozilla cuts that happened recently, because now how long are we going to wait for Servo to be in a usable state, if it even ever gets to a usable state?
Like you mention above, when you're forging a new trail in an underdeveloped area and making a case that users would benefit from these features if the ecosystem supported them enough and trained users to use them, you need some freedom to be flexible and experimental and to waste some resources forging that trail. And if resources are as scarce as Mozilla is claiming, then what are the features that are going to be cut first? The experimental, trailblazing ones, the weird ideas like, "shouldn't there be a section in the Firefox options where users can just live-edit the CSS to the browser?".
So I will concede that it is time to bury all the XUL/XPCom misgivings. We now need to rededicate ourselves to the same extensible vision using the new stack.
I think we need some kind of champion to make that point -- to prove that the extensible vision we did have and lost is still worth pursuing.
But that's not really a useful thing for me to say, because I have no idea where we can go to get that champion, and I'm at least low-key worried about Mozilla's ability and willingness to be that champion.
But agreed. I think it's about more than just XUL vs webExtensions, I think it's a broad tech/cultural issue about making the case that end-user-accessible control and customization is important.
> One question I have as a user - what is an acceptable grace period for coming up with an equivalent replacement when you take an API away?
Done correctly, the replacement should have already been there for one release before the deprecated method is removed; this is because the downstream developers also need to transition to the new code. Ideally there's some amount of time involved (so no releasing two versions in quick succession without letting people have time to move off the old way). That depends more on the scale of what people have been doing with your old APIs.
Note that the deprecated method only has to work; it doesn't need to be performant. That means doing it as a shim on top of the new way is fine (even though it's code that might be thrown away soon).
All of this has ~nothing to do with what Mozilla had been doing with Firefox, of course. I'm still waiting for features that existed in XPCOM that are no longer supported.
I don't care about XUL addons. What I cared about was addons with full access to the browser. I understand that they wanted to move, and that addons would break. But I would still love to be able to list non-sandboxed extensions in the store even if they came with a big warning "this extension will probably break with every new version of Firefox". There is still functionality that can't yet be replicated with WebExtensions.
For example I was maintaining VimFx as an unsigned extension for a while after it wasn't allowed in the store. Sure, it broke often, but the fixes were generally easy. However what really killed it was the lack of interest from not being able to be listed in the store and not being able to run on stable Firefox releases. If we could attract even a handful more maintainers I'm sure we could have kept it mostly up to date.
To this day I can't get back some of the functionality that I lost. Firefox is now just a different chrome. Sure, it is made by a different company, but the user functionality is now almost identical. (Sure, Firefox has about:config, but that is limited to what Mozilla imagined)
I'm really glad that Mozilla adopted WebExtensions. I think it is an amazing solution for most extensions. Plus it is safer and cross-browser. However there are a couple of extensions that need full access, and I wish that was still an option, even if there is no stability guarantee.
Question: would it be possible to restore the missing functionality through a companion process outside the browser?
Both Firefox and Chrome support the Native Messaging API [1] to communicate with a process outside the browser.
This would still be absolutely less than ideal as the process would have to be installed separately (I believe) and maintained separately for each platform - but it would allow the extension to be listed again.
For some extensions, yes. But the problem isn't so much sandbox from a security perspective, but the lack of access to Firefox internals.
For VimFx the primary problem is that it makes major changes to how input is processed. It can't get the level of input access it needs from the WebExtension APIs. You can see this in the WebExtension versions of similar vim-style binding extensions, I've tried maybe a dozen and none of them work as you would expect. It is common for inputs to be missed by the extension depending on what part of the browser is focused at the moment.
Honestly, your best bet now if you really want to target the stable branch seems to be to maintain a patchset on top of omni.ja. I see no reason that these type of modifications need to be dressed up like they're an extension.
Because it is convenient. I don't want build my own Firefox distribution on every machine I use. All I want is to be able to include a script into the browser's chrome process and have an easy way to publish and share.
This is basically Firefox extensions used to be. (well also XUL patches, but that could have been done with JS too)
Then build some tools to make it more convenient by applying the patches post-installation, and publish/share it on github? I just don't see how this is any more hassle then having something that you call an extension but that breaks every update and also needs manual fixing.
Why? I don't see a message that says it is only for stable addons. I don't care if they mark them as unstable, or hide them in the search, but I think itt should be possible to distribute them. I don't see why we would create a whole new infrastructure when one already exists. We just need to repeal the policies that they put in place and come up with ones that allow this type of "power extension".
You can distribute them on any other site. Somewhere like github would be happy to host them. Power users already know how to use those sites to sideload extensions. I don't see what benefit is going to be had from distributing an unstable extension that can potentially break every update, break the entire browser, steal passwords, keylog you, etc, alongside all the other stable extensions.
This article really doesn't match my recollection of how things went down. It implies that the switch to a multi-process model (Electrolysis/e10s) was held up pending the switch to WebExtensions. But I'm pretty sure I remember a transition period during which all my XUL-based extensions were either rewritten to support multiprocess or deprecated, which was years before XUL extensions were actually killed in favor of the less-capable WebExtensions. The article talks about this like it's a path they rejected, even though I'm pretty sure it actually happened. That transition was also a lot less painful than the switch to WebExtensions: over a period of several browser releases, I watched as the list of extensions preventing my browser from turning on the multiprocess capability dwindled. All the most important and popular extensions I was using made the switch smoothly with no major user-facing changes in capability or UI, which is the exact opposite of how the WebExtensions switch went.
It would really help if this article could use dates and/or version numbers to establish the timeline of events it's talking about.
(article author) Thanks for the feedback, I've just updated this part of the article to clarify it. I don't remember exact dates, though, so I won't be able to add them.
But yes, you are right, there was a time during which a number of old-style extensions were ported to be compatible with e10s. It was possible for some, impossible for others, hard when it was possible, and most add-on developers didn't port them, either because it was too difficult or because they had grown tired or the _maintenance tax_ I mention.
And yet, after they had ported their add-ons to be e10s-compatible, the add-ons broke nevertheless, one by one, for all the reasons mentioned in the article.
You threw in the towel before your most important extension developers did. Well-maintained popular extensions like NoScript and TreeStyleTab remained functional throughout the e10s transition with fixes delivered before the breaking changes in Firefox made it to stable releases, but they were irreparably harmed by the WebExtension transition. Their WebExtension versions are still not up to feature parity, despite ongoing maintenance.
It's quite obvious that the WebExtension model is better for users and developers of simple extensions. But it continues to not be an adequate substitute for the kind of extensions that gave Firefox real advantages over Chrome and other browsers. It's not at all apparent why those advanced, killer app extensions had to die in order to get the bulk of the extension ecosystem moved over to WebExtensions.
The author of NoScript was part of way more meetings than me during the design of the WebExtensions API, so he would probably be able to tell you more about what happened to his add-on.
> But I'm pretty sure I remember a transition period during which all my XUL-based extensions were either rewritten to support multiprocess or deprecated, which was years before XUL extensions were actually killed in favor of the less-capable WebExtensions.
It wasn't really years. Electrolysis went live in spring 2017 (it came with Fx 48 and was gradually activated till Fx54). Around that time was the first massextinction of addons.
WebExtensions and Firefox Quantum then came in autonm 2017 with Fx 57, finalizing the bigger second massextinction.
> Electrolysis went live in spring 2017 (it came with Fx 48 and was gradually activated till Fx54). Around that time was the first massextinction of addons.
Ok, so power users that mess with about:config (or users with zero extensions) were running e10s for more than a year before the WebExtension switch, and e10s was available in the beta and nightly channels long before then (ie. by late 2015).
But what's really important is that the process of enabling e10s was gradual and well-managed from a user perspective, rather than being a singular event that broke almost every extension long before viable replacements could be developed for most of them.
An alternative explanation about why XUL extensions needed to go by a Firefox dev Mike Conley [0], drawing pretty much the same conclusions and then some.
The same thing that happened to Firefox happened to Babel [1]. Babel's plugin API exposes the internal structures and APIs to plugins, which means they're unrestricted in what they can do, but it also means that it's very hard to change things in the codebase because you might accidentally break plugins that rely on the previous behavior / APIs. This is one of the primary motivations behind Rome [2].
So there's an interesting parallel in Rust with clippy, which is a linter that uses internal compiler data structures to parse and find the things to lint. This makes clippy very powerful, but very, very prone to breakage. Eventually, clippy was simply upstreamed into the compiler proper, which meant any refactoring of the compiler had to fix all the clippy lint at the same time.
Linux is similar with drivers. Linux breaks internal kernel ABI all the time, but all the drivers upstreamed into the kernel are automatically fixed when this happens.
According to OP post, Firefox and addons developer would communicate when breaking changes happened, to make sure an upgrade path was doable. I wonder if a Linux-like system where a repo with all addons that developers could land refactors on when landing breaking changes would have changed the dynamic somewhat, by reducing the "addons developer tax".
I'd like to live in a world were instead of developers just breaking an existing api, they leave the existing, in use apis and add new ones. It's ridiculous how often shit just breaks because an api is changed in an update.
Because in 90% of the cases the API isn't removed for fun but because something in the backend changed.
You can't just "leave the existing" as that still means work if you have to write some translation layer from the old format to the new format. It's not like it would be free to keep the existing one around.
I'm sympathetic, but literally most of the article is about how hard Mozilla tried to do this, and how it slowed them to a standstill and precluded improvements entirely.
I’d rather the main platform keep its internal codebase clean and streamlined, removing/replacing APIs whenever there’s a need, and publishing advanced warning so that plugin devs can update their plugins. Legacy plugins shouldn’t be a reason for spaghetti code in the main platform.
There's this project called "Microsoft Windows" that's done this for decades. You want to be the one digging through 1998-era C++ to fix a bug? Didn't think so.
While I understand from a technical and business perspective (particularly due to the security implications of needing to manually review each and every new addon) why Mozilla eventually went down the WebExtensions route, having personally revived the old XUL/XPCOM "MessageFaces" addon (a Plan9/unix era vismon/faces knockoff for Thunderbird/SeaMonkey) from 2004 when I was in college in ~2016, I was devastated to hear that Mozilla was removing support for XUL/XPCOM and the Add-on SDK from Firefox.
Nothing that the extension achieved is even remotely possible anymore — adding custom column in mailbox Thunderbird XUL, custom icon vbox in the Thunderbird mail header, reading from a browser profile directory to display picons, windowed preferences, etc. I find this sad.
What's most sad to me is that my workflow was never quite the same after I stopped using SeaMonkey with many of the famous XUL-based extensions (Old Addons Page, Chatzilla, MessageFaces, etc.) — it was aesthetic bliss, particularly with the Orthodox (Netscape/Mozilla Suite) complete theme.
I've ranted about this in the past, but I still feel like XUL was a bit ahead of its time (see Facebook's JSX). Had Mozilla invested more development time in fleshing out the XULRunner APIs and marketing it as a universal platform-independent "native" UI language, perhaps the modern web ecosystem would look a bit different today.
I fear that the web today is slowly converging, aesthetically speaking, through the further limitation of site interfaces and UI, into a corporatized unary devoid of any creativity/novelty.
as an aside, it was also extremely cool/interesting to me that i was able to get the extension working with only a couple of modifications to the XPCOM api calls that had changed between 2004 and 2016
But you said that you understand that from a technical perspective they had to replace it. That sounds more like a dead end than ahead of its time, unless there's something more?
IMHO, it was the wrong solution for a number of problems. Most of them don't exist anymore.
Sorry, i should have clarified — i feel like XUL, at a very early stage in the web's development, helped inform what advanced / platform independent interfaces might eventually look like (Facebook JSX -> React -> React Native, svgs, dom parsing, etc).
In recent years, particularly through the proliferation of things like JSX, javascript with XML-based extensions seems to be quickly becoming (for better or for worse) the dominant interface rendering paradigm.
I agree that XUL was, ultimately, probably the wrong solution due to a number of reasons, but its effects are definitely still somewhat visible in the ecosystem today.
What i'm still trying to figure out is how we recapture the freedom and aesthetic creativity that thrived during the early years of the web. We can argue that this was mostly a cultural/demographic shift in users, but I would also argue that, as McLuhan noted, shifting interfaces (particularly through a uniformity of aesthetics) can influence culture.
From an engineering point of view, it's understandable that XUL add-ons had to go - this article lays out the case very well. But from a product point of view, Firefox lost its "killer app". Now the choice to use Firefox over Chrome is mostly an ethical one. That's a tough sell for most people, and it certainly won't get someone who's never used Firefox excited to try it.
Chrome may soon give Firefox a little win here by nerfing uBlock Origin, but is that enough?
Yes, chrome was for a long time simply better browser (mostly because it was much faster/responsive).
But as the article explains, this was largely caused by the need to provide extensive backwards compatibility which stifled innovation or completely prevented it (in case of multi-process architecture).
uBlock Origin is already a bit nerfed on Chrome, and will likely be completely gone in the near future. That's Firefox's killer app for "regular" users, and power users too.
It's a matter of getting the word out. Mozilla likely won't outright bundle its features as to not completely alienate Google, since they are their main source of revenue, but seem to be okay with promoting it otherwise, as it is on the front page of addons.mozilla.org and was the first extension (and the only one, for a time, and still only one of nine) supported in the new Firefox for Android.
There are also "normal" users who do not care about blocking ads and tracking, or do not know about the performance issues, malware risk, and other reasons for using a blocker and have not made such a decision, trusting the browser to act in the best interest of the user. (We know that last bit doesn't work anymore.)
I understand the reasoning behind why XUL and XPCOM had to go, but I learned about this technology when I was in college, just starting to become really passionate about technology, and Mozilla sold these things as "important" ideas, technological paradigms that were not just the best way forward but would make the world a better place by making development easier, exposing more things to power users, allowing better sharing of common components, etc.
Except in the end these were not the best way forward (well, at least for now, old technological paradigms do come back periodically, making the whole idea of an obvious unified "best way forward" questionable), and so Mozilla had to ditch them, and I understand that.
But that means when Mozilla is preaching that WebAsm or Rust or whatever is a truly revolutionary technology that will save the world, well, I don't ignore Mozilla, I just don't trust in their technological foresight like I used to.
In the bigger scheme of things, I tend to be more skeptical that programming paradigms like this really are revolutionary in general. Programming paradigms are interesting ideas, but I no longer see them as some forward march of progress that is paving the way to a golden age of technology.
I feel a little silly that I once thought this way, and a little silly for once being as passionate as I was for Mozilla.
I relate to a lot of this post. There was a time when it was totally obvious to me that XUL was going to take over the computing world. And whenever someone came up with a new technological paradigm, promising it would solve All The Problems, I either believed them or strenuously objected, feeling threatened by the idea that everything I knew was going to be invalidated.
Now that I'm old and jaded, it all seems silly. There are no silver bullets, everything is at best an approximation of a great idea that would solve at most a small fraction of all the real problems out there, etc.
I'm still pretty invested in Mozilla (ok, I work here now), but more for the good of human advancement and discourse, and an actually useful portable runtime that is kept free from being captured by entities that would inevitably use it as a weapon for lock-in and monopolization.
Things aren't looking all that great on the latter front right now, and indirectly though it might be, Firefox's market share is one of the most potent defenses against that. Even if Mozilla has a trail of missteps and lost opportunities. (To be honest, I actually think Mozilla has done far better than is commonly portrayed on this site. It's amazing how many people could obviously done vastly better than the idiotic monkeys running Mozilla into the ground for their own small-minded amusement.)
I think you're confusing the implementation with the idea. XUL wasn't the right path forward for bringing web technologies into the desktop as we can see with the failure of XULRunner but a ton of apps are written today with Electron and HTML5. E4X was an interesting idea bringing XML into Javascript as native objects, but the ultimate implementation lives on as JSX with React.
As someone who had to maintain E4X within SpiderMonkey: sadly, that's another great example of the wrong technological path. JavaScript is too dynamic, it gives you too much rope to hang yourself, and E4X was apparently not designed with that in mind. It was so nice when we removed E4X and didn't have to worry about `x` being an object during a lookup `obj[x]`.
To give an example of the flavor of issue: when building an array (even from a literal), you couldn't push a series of values to the stack and then construct an array out of them, because with E4X between elements 2 and 3 you might end up invoking arbitrary code with access to the array so that it establishes a setter on element 4 and adds a `valueOf` hook to what you're passing as element 5, but oh wait that's the same object you already inserted as element 0, and anyway the array might be frozen now and... (I'm making this up; I know the issues were similar to this but I probably don't have the details quite right.)
E4X was a rich, rich source of security bugs. I'm sure a simplified form of it is possible and would be quite cool, but that niche is already filled now with JSX for better or worse.
Rust - noted by a wide cross-section the industry as a huge step forward in memory safe languages - and XUL seem like an unfortunate equivalence to draw.
This is a great article but it saddens me that it had to be written because all these years later, community members are still mad their extensions don’t work.
I guess I’ve underestimated all these years that what David described as the problems with XUL and the reasons it had to go away weren’t commonly understood. As the post states, it was clear as far back as 2010 (and honestly earlier), that XUL extensions were both Firefox's killer feature and also the reason that it got its ass kicked by Chrome (and to a lesser-extent, Safari). Extensions were amazing but the tax it created for performance, development, and security ended up becoming what made the browser so slow. Chrome and Safari didn’t have extensions but they had speed and built-in features that replicated many of the most popular extensions. And once Chrome added extensions support — and support that didn’t require that add-on development tax — it was over.
I found this bit of the post really telling:
> And yet, there was no choice for Mozilla. Every day that Mozilla didn’t ship Electrolysis was one day that Chrome was simply better in terms of architecture, safety and security. Unfortunately, Mozilla delayed Electrolysis by years, in part because of the illusion that the Firefox benchmarks were better enough that it wouldn’t matter for a long time, in part because we decided to test-drive Electrolysis with FirefoxOS before Firefox itself, but mostly because we did not want to lose all these add-ons.
>In the end, Mozilla decided to introduce WebExtensions and finally make the jump towards e10s as part of the Quantum Project. We had lost years of development that we would never recover.
This aligns with what has always been my personal view which is that Mozilla waited too long to make the changes it needed to compete with Chrome and by the time it finally did the hard thing and lose extensions and start over.
When you consider that there was still time after Chrome was released but before Quantum where IE had the largest browser share (it wasn’t a long period of time post-Chrome, but it existed), that’s indicates to me that there was time both before and after Chrome's introduction for Mozilla to rip the band-aid off and drop XUL for the greater good of the browser. After all, IE didn’t have extensions in any comprehensive way, which could have given Firefox to refactor and approach. Sadly, Mozilla waited too long.
But what really makes me sad is that there are still diehards mad that XUL died. When to me, we should all be angrier that it was allowed to live as long as it did.
> community members are still mad their extensions don’t work
I suspect a lot of these people aren't very familiar with the details of the technology involved, or the tradeoffs involved. The were simply (understandably) upset when suddenly their favourite extensions stopped working. And in the early days WebExtensions, there weren't any good replacements for a lot of popular plugins. Even now, there's no way to do some of the things plugins did before.
I am very familiar with software and in particular the tradeoffs between business pressure to ship something new and shiny vs keep maintaining something that works....
Just because you are a developer doesn't mean you necessarily understand the challenges of writing a xul plugin that doesn't break other plugins, and doesn't break on every browser upgrade.
We know exactly what Mozilla said and yet my actual experience before the change Firefox was performant enough whilst having exactly the UI I wanted and never crashed whilst after the change Firefox uses all the memory on my system has crashed several times (also the memory hogging causes swap issues which are as bad as a system crash) AND the UI is worse.
I used to use FF because it was better than Chromium. Now I used it because Mozilla is not Google.
We* are still generally better at that, but there are many different situations so different users have very different experiences. Please file a bug, preferably with an about:memory report while the browser is using an uncomfortable amount of memory. (You can actually get more info using the Memory tool in devtools, but it's trickier to use and doesn't work after the memory usage has gone too far.) A profile https://profiler.firefox.com/ could also be useful -- it'll record what addons you have, for example, and memory use over time -- but we can figure that out in the bug.
It crashes my whole linux system. Is about:memory preserved on restart? Is it safe to send my employer's data?
I've largely switched to just running FF inside a VM. It seems to use all the available memory in a given system so I just give it less memory and it performs about the same...
Enable SysRq magic key and use it to invoke OOM killer manually when it freezes. Linux has this weird peculiarity of not invoking OOM killer automatically before system exhausts memory. (and instead just runs extremely slowly, shrinking buffers to zero and loading executable pages from disk)
>Firefox's killer feature and also the reason that it got its ass kicked by Chrome
5% faster page load still isn't a killer feature.
>Extensions were amazing
And the reason everyone who left used the browser.
>lose extensions and start over.
A smart company would never have done this. They would have maintained both to see if anyone would use the new browser. Instead, they took their customers on a forced march down a trail of tears.
Imagine if another company tried this. Imagine if Tesla said, "We know you love electric cars. So today we're going to stop making them and sell hydrogen powered motorcycles instead. They're faster! Sorry, we won't be making parts for or supporting the cars anymore." It would be corporate suicide. Imagine how angry the car owners would be, after they invested in the idea and the charging equipment, only to be abandoned by the company.
It makes perfect sense to continue shipping the old product in the face of a "new better" one. Apple continued selling iPods long after the iPhone arrived. Killing the successful core product and releasing a new untested competing product is an insane gamble. I can't see how Mozilla leadership ever thought that was a good idea.
Over many years, I had to port an addon from Greasemonkey to XUL to Jetpack to WebExtensions. The number of add-on users steadily dropped as the number of Firefox users dropped.
Now, if you write a Firefox extension, and it's not a Mozilla-recommended extension (something you have to beg for) anyone installing it gets a scary notice:
"This is not monitored for security through Mozilla's Recommended Extensions program. Make sure you trust it before installing."
This is after going through Mozila's approval and signing process. Unsigned extensions won't install at all in the release version of Firefox.
Firefox extensions aren't something worth working on any more.
> Firefox extensions aren't something worth working on any more.
Unfortunately I now totally share this sentiment, I had an extension that delayed page loads in a realistic way to test slower connections. I started on back when XUL was the way to do it but dealing with the churn led me to give up. When XUL was being deprecated I ported to the newer way but I could tell that the churn was starting to get annoying and that my enthusiasm had changed. As much as I would have liked to continue work with that extension with the recent changes I'm glad I gave up when I did.
I'd really like to see something change to make working on extensions feel like it's more worthwhile again. Do people think that things are likely to stabilize in the next few years?
Browser extensions are probably going to go away, at least in Chrome. Google needs to control ad blocking. They've never been a big thing on the Chrome side anyway. Firefox is down to 8.61% market share worldwide.
As Google removes user control, they can make Firefox go along, since they're Mozilla's biggest revenue source.
Let's be clear on one thing that seems to be perpetually discussed whenever there is a Firefox thread: what has lead to its declining usage.
It is not removing XUL 'power' extensions and replacing them with 'neutered' WebExtensions mechanism.
It is not choosing to closely align with Chrome in terms of UI/UX and functionality.
It is not the letting go of Brendan Eich and the newer (much criticised) management.
It is not because of Mozilla foundation highlighting a few 'social justice' issues here and there.
The decline of Firefox is because of one thing only - the enormous marketing and engineering clout of Google and their utterly ruthless, relentless, anti-competitive pushing of Chrome across Android and all their web properties and even through ads all over the world.
More specifically, it is their bundling of Chrome as the default, preset browser on the world most popular mobile operating system that really swung the tide decisively in their favour. Once ordinary users got used to Chrome on Android, they would naturally seek out the same browser on their laptops and desktops, to minimise interoperability issues and maximise familiarity.
And while pre-installing Chrome on Android (and by the way, it is pre-installed even on most laptop/desktop purchases by "helpful" OEMs - such is its viral reach) may not be strictly illegal as per anti-monopoly laws (because alternatives are 'freely' available on the default app store), the fact remains that if a program that comes with the OS is "good enough", the very vast majority of users will not bothering changing it, and thus Google managed to cripple all other browsers while still subtly side-stepping any potential lawsuits.
So the decline of Firefox is in my opinion a social/political phenomenon and nothing to do with its technical competence or extendibility vis-a-vis Chrome. It is certainly a more than competent drop-in replacement for Chrome (unlike say w3m or NetSurf), but who will bother to do the replacement in the first place, as long as Chrome continues to be "good enough" (which is does excellently) and it doesn't outrageously hurt the user base by some extraordinarily shocking screw-up (and Facebook shows, even such odious abuse will be condoned by the user base by and large when the network effects are too big).
> The decline of Firefox is because of one thing only - the enormous marketing and engineering clout of Google and their utterly ruthless, relentless, anti-competitive pushing of Chrome across Android and all their web properties and even through ads all over the world.
That probably had an effect, but I don't agree that its the single biggest factor. Before Chrome arrived, my experience in general was that Firefox had gotten slow and buggy, and when one tab crashed the whole browser went down with it. It was a once great product that had stagnated.
Compared to that, Chrome was a breath of fresh air, so me and many people I know migrated and then recommended it to friends and family. That had nothing to do with the Android version; at the time I didn't even have a smartphone, and many other tech people that migrated had iPhones. The desktop browser was simply a better product; and since at the time Google wasn't considered evil, and its Chromium base was open-source software, there was no reason not to use it.
I eventually migrated back to Firefox myself, and am currently very happy with its performance, stability, and exploration of privacy features like Container Tabs. However, it wasn't before e10s I felt I could really recommend Firefox over Chromium to anyone else.
I worked in a non-tech office where people used Firefox. At one point firefox was taking 30 seconds to load. I’d experienced this too and it seemed to be a bug in the profile manager. Nonetheless my colleagues were unimpressed.
This was before Chrome was released. And when Chrome was released it was frankly better for most users, even without extensions at the start. Yes it was heavily advertised, but it also felt faster and gave a better experience.
Now Firefox after the quantum reactor, and getting rid of XUL, upsetting plugin users, has caught up with Chrome—but they did this from what was once a leading position, and getting back those users lost seems less likely.
> I’d experienced this too and it seemed to be a bug in the profile manager.
I'd experienced this as well, and the most common fix was indeed to create a new profile and import your bookmarks/etc - but at least for me, it was totally unnecessary: All I had to do was delete history older than 6 months, and it was back to being snappy as new.
You're saying that Google is so amazing at marketing, that they beat Apple, Microsoft and Firefox at marketing that browser, although Chrome wasn't even the default preinstalled browser on most devices? Chrome isn't the default on Windows, it's not the default on macOS, it's not the default on Linux, it's not the default even on most Android devices (Samsung Browser is, since Samsung is still handling the majority of Android market, followed by Chinese manufacturers who don't bundle Chrome at all).
That for all the efforts of Apple to push Safari as default, Microsoft to push Edge as default... Chrome had no other merits than just ONLY Google marketing which has somehow managed to beat out the default preinstalled well marketed browsers without any special additional technical merits?
You reasoning is missing something fundamental. Is it possible, and entertain the thought for a bit, that Chrome was just the better browser for a long time? Maybe?
> You're saying that Google is so amazing at marketing, that they beat Apple, Microsoft and Firefox at marketing that browser.
Google literally had a banner on their homepage prompting users to try Chrome.
E: Of course, I don't mean to say Chrome was a bad browser and won entirely through marketing. But its current market position has as much to do with Google's explosive marketing (they had billboard ads for Chrome! For a free browser!) as much as with Chrome's technical qualities.
Google spent money to market Firefox as well. Back in 2005, they'd pay $1 commission per successful install of Firefox with the Google Toolbar included. I don't recall when they cancelled that offer, but it ran for years.
For comparison, I've read estimates (I don't know whether they're correct) that the marketing budget just for launching Chrome was equivalent to two billion dollars, if you include the ad space that Google was providing for free.
That's just for the launch.
I may be forgetting things but I don't remember ever seeing launches for a free product that were so heavily marketed.
I don't know about the money they spent, but I believe thinking about it as a free product isn't the right approach. It delivers data & insights and gives them (some) control over the platform that powers their core business, much like Android gives them (some) control over the mobile platform. That's probably well worth whatever they spend on it.
With Firefox and Chrome (and Chrome forks that aren't independently developed, but mostly kept close to the source with some added functionality), they're offering all the options on the market (except Safari, but it's not an option on the global market, only on Apple), if you want a Browser, you'll use something Google-controlled, one way or another.
Yoric wasn't referring to actual money that traded hands; the 2 billion USD figure included the estimated value of being featured on google.com.
And I'm certain that Google determined that whatever they paid for it (in cash or opportunity cost or whatever) was worthwhile to them! (And today, it very much looks like they were right.)
And the competitors literally put their browsers on your device, with prominent icon and set to open every web page without having to download anything. Yet people still chose to get Chrome.
Without recognizing good things Chrome does, there cannot be a viable competitor.
How often do you see a browser icon on your desktop? Yep, it's always there in the task bar or the dock, but it's not your focus.
Now, how many times do you search for things on web? Every search page and search results page had a call to action to install Chrome. It's the only product Google advertised on their home page for years. The download was tiny (it downloaded the rest of the app in background), it did not require admin rights to install and hijacked the default browser setting.
Plus Google put aggressive ads on YouTube, in Gmail, Maps and Docs at the time. One click on a banner, you browser showed a dialog - and bam! You got Chrome.
Plus, there were bundles with Flash player, Skype, all popular antivirus freeware, etc. In 2010-2014 it was almost impossible not to have Chrome on one's computer on accident.
And many banner ads in major cities around the world. London underground was flooded with Chrome banners - something no other browser had done before or since.
And in those very early days, Chrome would put itself on your computer uninvited: Installers included it as extra recommended software, at which point it would set itself as default.
My friends and I stopped using Firefox after they broke our favourite XUL extensions. So did my parents. So did many, many developers I knew.
Everyone moved to using Chrome and never went back. Breaking XUL dropped Firefox adoption considerably. But folks who did this don't want to accept it.
XUL extensions gave Firefox unique power which it lost and never regained back. Firefox chopped off its powerful , special tentacles and grew flimsy, poor hands back. Firefox defanged itself.
Your favorite XUL extension broke so you "solved" that by migrating to a completely different browser which also doesn't provide the desired functionality.
Why do you think it doesn't add up? Before the removal you have
"usefulness of firefox" + "usefulness of extensions" > "usefulness of chrome"
after removal
"usefulness of firefox" < "usefulness of chrome"
And that's not counting disappointment/animosity towards firefox for breaking the implicit contract.
I am not arguing that this was the main issue that have caused firefox usage to drop, as according to stats on AMO, extensions never had very large usage. But i personally have stopped using firefox after this, and stopped installing it on computers of friends and coworkers, so there must have been some small effect.
> "usefulness of firefox" < "usefulness of chrome"
This was the missing hidden variable not explained in the narrative.
Firefox was previously significantly behind Chrome in the technical design, now it's getting better but there is still some lag.
And as explained in the article, this lag has been historically to a large degree caused by the extension model (need to keep backwards compatibility on a huge API surface, impossibility to introduce multi process architecture, need to always negotiate with extension devs on what can be changed and what not...).
There were two options:
1) specialize on power users with XUL extension but lag even more behind Chrome - leads quite certainly to drop of users, slide to irrelevancy and the eventual death
2) try to catch up with Chrome in technical design, but drop historical baggage, including XUL based addons - does not guarantee success but still provides at least hope
> ... and stopped installing it on computers of friends and coworkers, so there must have been some small effect.
It's sad to see people supporting monopoly this way ...
> It's sad to see people supporting monopoly this way...
The realistic way to avoid monopolies and retain free-ish markets is to actively enforce anti-trust legislation. (And in the case of social media companies: force all players of a certain size to provide federation APIs, so people can leave the service and still talk to their friends and family.)
There will always be some people that try to avoid monopolies for ideological reasons; but 90% of the population won't care, they just want things to work and move on with their lives, and capturing that segment still makes you a monopoly.
> but 90% of the population won't care, they just want things to work and move on with their lives
Yes, I meant it more specifically that people here on HN who should know and should care are actively propagating and helping a monopoly. (these people often also have disproportionate influence)
What do we get from supporting Firefox against the "monopoly" though? Chromium is as open source as Firefox, and users have as much influence on features Firefox implements as on features Chrome implements, which is zero. I would wholeheartedly support federation apis, as parent comment suggests, standardization of browser sync api, etc. But i don't see what does Firefox accomplish now about which i should care.
When google controls the only remaining browser engine, it effectively controls web standards (or in other words, independent standard documents lose meaning since Blink is the standard).
Google is then free to push the web technologies in the direction which benefits mainly Google (think AMP) and which further tightens their grip on the web.
> specialize on power users with XUL extension but lag even more behind Chrome - leads quite certainly to drop of users, slide to irrelevancy and the eventual death
Ah yes, if you're reduced to power users your death is inevitable. Which is why Linux, of course, is a myth and does not exist.
It is a combination of factors, it always is. At the time of XUL removal Firefox didn't have much else going for it in terms of performance and stability, such improvements came later on around the time Quantum released, at least in my experience with it. I would very often use XUL extentions for their unmatched capabilities, one of which I fondly remember was Norwell, unparalleled anywhere else. Once XULs were gone, to me, there was nothing noteworthy about Firefox compared to other alternatives, except perhaps allegedly being more "privacy friendly". I just kept going with it as I did for more than a decade by inertia, and can see why someone would drop it for else.
> At the time of XUL removal Firefox didn't have much else going for it in terms of performance and stability, such improvements came later on around the time Quantum released
It was exactly Quantum release which took away XUL extensions.
Ah, my memory is terribly hazy then, awful mistake that also shows my bias. Anyhow, I think it is a shame capabilities, performance and security cannot coexist yet in browsers. Wish WebExtensions would get more attention to extend their APIs, surely more powerful extentions are still a significant strong point in choosing a browser.
Quantum was the big break, but XUL extensions were getting broken with greater and greater frequency leading up to it. So your memory is probably fine!
I agree that the number and power of WebExtension hooks is critical.
this makes sense, but not from a technical point of view.
our brain is hard wired to respond to negative actions much stronger than positive ones. this comes from the not conscious part of the brain and it happens because it was much important in our early history to respond to threats, than it was to respond to good things.
consider this: how often have you stopped using a bank/restaurant/whatever else because they did something bad to you? how often have you switched just because somewhere was better, but not way better? a positive action has to be much much stronger in order to compete with a negative action.
At the time, Chrome had Chrome Apps. If you recall, several XUL extension authors quit in disgust and started developing chrome apps. Google wasn't considered 'evil' at the time...
Firefox had a unique, special power which differentiated it and Mozilla chose to kill it. No wonder its browser share dropped like a stone.
Chrome Apps were in no way replacement for XUL. They could not change the behavior of the Chrome itself, they just opened their own window and did their thing there. Not really an extension, more of a separate app.
To talk on more specific terms, which XUL extension did you replace with Chrome App?
I finally ended up using alternate tools since even the replacement Chrome Apps were pale imitations of what Firefox offered. The good ones needed to use Nacl just to do basic stuff and still couldn't reach what XUL extensions natively supported.
But I changed my browser to Chrome since Firefox lost its value proposition. It had a differentiating factor of superior experience and features that it chose to deliberately abandon.
The removal of XUL extensions triggered a large outcry among developers and power users, but I don't think it was all that relevant if you look at the graph of Firefox's declining market share. That was driven far more by Chrome's increasing share.
"Components" may have been the wrong term. I meant to say that you can give WEs access to something that lets them access the same things that JS running in the browser can. My understanding is that this is currently most easily done via XPCOM interfaces accessible from |Components|, but I wasn't trying to suggest that it needed to be done via XPCOM. Do it using whatever technology the browser itself is using.
There are many things that WebExtensions could do, if only we found the time to add the necessary APIs.
Sadly, Firefox has to race against Chromium with about 1/4 of the developers (I don't remember where I got that estimate from), so we have to focus our efforts. As you can imagine, Mozilla's comparative lack of resources (hence the recent layoffs) won't improve that.
One other thing that is missing here is that Firefox was trying (and still is) too much to be an "app store" and "sandbox" for extensions. This is not what we should be expecting of a browser, and again goes back to another point someone else made in this discussion is that Firefox is chasing "huge" marketshare instead of focusing on its core and growing organically from there.
What that metric-chasing meant is having their extension store spammed with useless extensions. I think that extension-count was a mistaken metric to chase, and no wonder they felt overwhelmed with trying to support spam-level amounts of extensions.
At it's core, I think this entire debate boils down to "who is responsible if an extension breaks the browser or some other extension". A relatively small set of "complex" or "tightly integrated" extensions that enhance and extend Firefox's behavior is a good spot to be in. Rather than what we have now where all the "interesting" browser extension points are not available to the extensions to modify and we have a metric tonne of copy-paste-similar extensions that are hard to discover.
I've never seen Mozilla promoting the number of available extensions, and I've never heard that it's a significant metric they track internally. The addons site highlights a relatively small number of popular extensions, with some categories (e.g. password managers).
The blog post describes how Firefox tried to focus on its 'core' - assuming you mean people heavily invested in XUL add-ons - for years before they eventually decided it was a road to nowhere.
Microsoft was convicted by the US for tying Windows and IE in the 90's, and Google was more recently convicted by the EU for tying Android and Chrome. US regulators have declined so far to do the same for the latter, although the political winds seem to be changing.
> The decline of Firefox is because of one thing only
Personally I would use Firefox if it was not slower than Chrome. I like most things about it more, but it is noticeably slower in some cases, it randomly becomes unresponsive in some cases and it consumes more system resources.
And actually when they dropped XUL I started using Firefox a lot less than before because now the extensions that kept me using Firefox were no longer available.
Maybe it is just me, but I really do think there is plenty Firefox is doing that hurts them. I really really want to like Firefox, and I really don't like chrome. But for what they are, browsers, Chrome is better than Firefox in my experience.
> More specifically, it is their bundling of Chrome as the default, preset browser on the world most popular mobile operating system that really swung the tide decisively in their favour. Once ordinary users got used to Chrome on Android, they would naturally seek out the same browser on their laptops and desktops, to minimise interoperability issues and maximise familiarity.
Most android phones I've had have shipped with a stripped down "web" browser as the default.
I use primarily Chrome on my Android phones because performance is consistent. I keep Firefox (with an add blocker) installed and use it for sites where that's needed, but it just doesn't do a good enough job to me fore regular browsing on mobile. This is the same reason I used to stick with Chrome on the desktop too, though since Firefox Quantum I've been able to cope with Firefox for regular use on the desktop.
Chrome had already beat Firefox' in market share before it was even released on Android. Unless they included time-travel in that release, there's no way that influenced them overtaking Firefox before it happening.
When they released on Android, Chrome already was the biggest on Windows, having surpassed Internet Explorer as well.
Sorry, but you're either intentionally misleading people or you haven't actually looked at the timelines.
And they did aggressively market it to get to that point.
If you visited Google on Firefox or IE you would get a banner suggesting you to try Chrome.
It was bundled with all sorts of software, including Flash which would install it by default unless you found the right checkbox. (Many non-technical people I know ended up unintentionally installing it this way)
They even had offline (real-world) advertising for it.
I'm sure word of mouth had an effect, but it was only a small part of why it succeeded. Remember that Firefox only ever achieved a fraction of Chrome's (current) market share, and relied mostly on word of mouth (though they did have the occasional real-world ad campaign), despite its superiority to IE.
> If you visited Google on Firefox or IE you would get a banner suggesting you to try Chrome.
Let’s not understate this, as I remember it clearly.
As a Firefox user, using any Google-product on the web, I was constantly badgered to “upgrade” my browser.
That’s right: Google lied and told Firefox-users that they were downloading upgrades to their Firefox installations.
Completely inexcusable, fraudulent behaviour. Combined with the bu sling and drive-by-installers Google paid for, me and lots of my technical friends still consider Chrome genuine malware for this reason.
Sure, and as I mentioned elsewhere: before they had Chrome, they aggressively marketed Firefox, paying referral commissions for every Firefox install that included their toolbar. That was in 2005/2006 and ran for years, and was a large part why Firefox became successful: websites got paid to recommend it to their users.
Marketing is a large part of everything, I agree. But the argument I replied to was that it was the monopoly & bundling that made it successful. That's obviously completely false and pure propaganda, trying to absolve Firefox of anything and everything, essentially saying "none of those things matter, it was only Google's evil behavior".
> I'm sure word of mouth had an effect, but it was only a small part of why it succeeded.
I'm not so sure. Internet Explorer as "the perfect tool to download Chrome" wasn't a meme because people watched ads, but because Chrome (on Windows) was easy to download & install and fast & stable. Firefox wasn't any of that in comparison, that's why lots of people I know switched to Chrome back then.
And once you've gotten used to something, you really need a reason to switch back - something that Firefox never provided. Privacy might become that, but Chrome with plugins isn't terrible either, and Firefox sent data to Google for analytics "out of the box" as well (and probably still does?).
I understand that it's nice to have a boogeyman that can be blamed, but I don't think that's accurate. Firefox lost because of Mozilla, not because of Google.
I was with you for the first 5 lines - it's not because of any of those reasons.
But listen to the Firefox developer in the article - Chrome was making a better product because they weren't tied down with backwards compatibility issues. It was genuinely faster, more secure and they were shipping features quicker. Meanwhile Firefox wasted years attempting and failing to become multiprocess because they were tied down with the legacy of XUL.
But you have to give Chrome credit for making a good product. No doubt marketing helped, bundling with Android helped. But for a solid 5-7 years, it was clearly the best. And I say that as someone who has used Firefox for a decade.
There was definitely a time we're Firefox had performance issue.
I don't speak of those benchmark milliseconds things.The entire browsers was so slow scrolling was a problem and more and more time the entire OS (Mac os) freezes for 10 seconds or so.
That's where I left and years later why coming back if it doesn't have any more interesting features than chrome.
> I don't speak of those benchmark milliseconds things.The entire browsers was so slow scrolling was a problem and more and more time the entire OS (Mac os) freezes for 10 seconds or so.
Could it have been every 15 seconds?
I think I was part of the team that fixed that bug :)
Hmm. In the beginning on Andorid, there was nothing called chrome. Only a primative, webkit based browser usually called "internet" that OEMs would customize. Other browsers have always worked fine on Android - from Dolphin to yes... Firefox. I'd say that Firefox on Android wasn't suitable for daily use until sometime in 2019... and there's still a lot of work to do.
Chrome on Android is a miserable experience right now because someone at Google thinks that hiding URLS and making it difficult to edit them is a feature.
The user experience of Chrome is just better for non-geek users. This makes a big difference although geeks have a hard time accepting that this should matter.
> The decline of Firefox is because of one thing only - the enormous marketing and engineering clout of Google and their utterly ruthless, relentless, anti-competitive pushing of Chrome across Android and all their web properties and even through ads all over the world.
OK, so your answer is that world is super simple and comes down to a single variable explaining everything? Sorry but that does not sound very convincing to say the least.
There was a time where Firefox needed to be installed manually on Windows where IE was provided by default and it become the leading browser. Ask yourself why it's not the case anymore.
>The decline of Firefox is because of one thing only - the enormous marketing and engineering clout of Google and their utterly ruthless, relentless, anti-competitive pushing of Chrome across Android and all their web properties and even through ads all over the world.
I went so Safari as my default browser when Firefox (which I was using from Phoenix 0.3 irrc) became slow and bloated.
Chrome and Google marketing had nothing to do with it.
You're certainly right but it also didn't help that Firefox for Andorid was _really_ bad for a long time. Fenix is a glimpse of hope but it came to late.
Me and everyone I know stopped using when they removed XUL extensions, that may not be representative of the general populace but losing the mindshare of power users could not have helped them. For a decade when non technical users asked me what browser to use I told them Firefox, that stopped then they abandoned powerful extensions.
Google's anti-competitiveness is easily the biggest reason Firefox doesn't have a majority market share. I would argue, however, that several of those things are the reasons Firefox can't hold onto a minority share either. Sure XUL, themes, tabs on bottom, etc were never going to keep Firefox on top but they might have been enough to hold onto 10%.
Google is evil so I still use Firefox, but it just feels like Chrome without Google. The evangelizing passion I had for it ever since version 1.5 is dead and Mozilla killed it.
This feels analogous to videogame modding. You either let/don't prevent the modders from messing with the very core of the game, which brings total overhaulability but also total vulnerability and jankiness; or you give them a nice modding API that, depending on how much effort you put into it might be rather powerful, safe and and convenient but IMO is fundamentally crippled in comparison to the former approach, it's as if you have to imagine all the ways people might want to mod your game beforehand.
Also, I have this bad taste in my mouth from Mozilla getting all that Google money just hours after sacking their developers, like it was a condition.
Third option: You give them a nice modding API and let them access the core of the game. That way you gain the benefits of a modding API without restricting modders' creativity.
Only a third option if you don't care about all the problems the article tells us about. Full access by third party developers and being able to update code are simply at odds with each other. There's no way around it.
Allowing addon developers to access private APIs simply doesn't prevent Mozilla from changing them, or anything else. An unstable API is much better than none at all.
It's a good article, but in my experience explaining this stuff over and over again in HN and other fora, people don't actually want to know. They have their narrative and they're sticking to it.
> They have their narrative and they're sticking to it.
That's exactly how reading Mozilla apologetics comes across. I'd say pre-registration could help sift out the bullshit from the well-founded predictions, but there's seemingly no way to get Firefoxers to deviate from their narrative, and the proof would come at a time that's too late to act on, anyway.
For all the retrospectives that exist about Jobs's ability to captivate, Mozilla folks have a self-perpetuating echo chamber/reality distortion field of their own—except the only thing it's good for is a thousand self-inflicted wounds and a smug sense of persecution. Terrible combo.
I'm hoping it will be valuable to use as a link to point people to. Right now, it's more effort than it's worth to rehash bits and pieces of the argument. I'm bookmarking it for future use.
My issue is simply that I want an extension mechanism which I can use to do anything to my browser. For me, 'extension security' means 'I must write C++ to add the functionality I want,' and I never, never want to write C++.
What prevents you from writing a patch for Firefox then? After all, it is one of the great advantages of FOSS. At this level of power you'd likely have to change the addon every upgrade anyways.
because what you are purposing is fork a browser which is only slightly less complicated than fork operating system and involves a major investment in time/money to maintain.
So would an extension with that kind of power. FWIW, extensions as they are already do require quite a bit of maintenance, and it is also reasonable unlikely that any one source file would be modified in one given update.
I've wanted something more like Emacs for the web -- a bunch of fast primitives and hooks everywhere, with a good-enough language to allow me to modify everything about the browser as I see fit, without having to drop down into the C++ hex mines.
I think this is the honest answer. The people upset simply don't want a browser with measurable market share. In the Stack overflow survey Emacs has a market share of <5%. Non programmers have never heard of Emacs. If Firefox was targeting these users there would be no Firefox...
Right. My old boss at Apple used to encourage me to rant about how our products should work, and then shake his head and with a Gallic chuckle say, "we'd go broke if we made products for you".
That's exactly what I want: an Emacs for the web. Or enough web-browsing capability built into Emacs to just browse every site in Emacs.
Seriously, though, I want the software I run to obey me, not someone else: not Microsoft, not Apple, not some government on the other side of the world — and not Mozilla. I want to be able to modify its functionality in a straightforward manner, in a reasonably-sane garbage-collected language (so, not C, not C++, not Java and not JavaScript).
I would like to be able to add pull data from sites I visit and plumb it through the rest of my system using something like Plan 9's plumber. I don't want a browser which says, 'sorry, I won't trust you to choose the extensions you like.'
There are still some forks of firefox around, you can use those. I'm glad they traded out some configurability for security and multiprocess browser. I'm sure they would accept any patches from you that allowed the old configurability with the current performance, stability and security.
So, install Firefox 56, or 52 ESR, and never update it. Or run PaleMoon or one of its relatives, I suppose; that community's doing what it can to preserve archives of XUL-based extensions and API documentation.
This may be an unpopular opinion: I'm very grateful for all browsers to switch to WebExtensions. To me, for the web to win as a platform, standards are a must.
I'm a new WebExtension indie dev. I just launched my first extension on the Chrome, Firefox, Edge stores. Opera is in review. Safari 14 took 15 minutes and 1 commend, just waiting for it to drop. I couldn't have shipped this quickly by myself if not for the WebExtensions standard. It leaves me time to focus on building what users want and telling users about what I built. Yes I did have to settle for less developer power and control. I'm totally ok with it.
Hmm. As a crotchety old man (well, I'm 32, but still), I hadn't even considered mobile. I was thinking Windows/macOS/Linux native apps as the probable alternatives.
In either case though, I think this is just one more reason to hate Web Extensions. I don't want browsers to win over native applications. (Of course "applications" that are little more than a bundled browser are even worse, whether on mobile or desktop.)
@ebruchez is right. Also by win, I really mean to compete head-to-head with the native platforms. I love a good native app as much as anyone. The recent Epic vs. Apple fight shows that we need more open alternatives like the web platform. Ones that are free to develop for and free to distribute. I'm looking at you Apple, charging me $99 for a developer account just to distribute a Safari 14 web extension in the app store.
Funny seeing this here, I just switched to Vivaldi yesterday because of this.
I really wanted to use mouse gestures and Vim-like controls again, and the WebExtension version of those addons is not nearly reliable enough.
The problem seems to be that those control extensions can only work by injecting Javascript into webpages, which (1) takes a moment to work when the page is loading, and (2) doesn't work in New Tab page. The effect is that even basic shortcuts like "next tab" fail to work often enough that I'm willing to switch browsers.
Thanks for the article, it provides very good insights.
In the article, there are a couple of passes that mention “benchmarks” where Firefox was faster than Chrome. It sounds like those benchmarks, albeit I assume they were correct, were actually providing a distorted reality of what “fast” actually means, because I distinctly remember people (including myself) switching to Chrome in early days because it was simply objectively faster. It sounds like the existence of those benchmarks have had a net negative on Firefox: it provided a false confidence that the browser was “fast”, and possibly delayed the refactorings that eventually managed to really speed up Firefox again.
You mention that Chrome used “UX tricks” but I assume what this means is that Chrome developers were actually driven by more correct benchmarks: the ones that actually translate to a better experience for the end user.
Since I’m always intrigued by the topic of false benchmarking and how complex it is to do correct benchmarks that don’t fall into traps, I’d love to hear what those benchmarks you mention were measuring, and if you agree that they gave a false assurance to the Firefox team.
To summarize, we were benchmarking for throughput: how long between the time you click and the time the operation terminates. For a long time, we absolutely crushed Chrome on most of these benchmarks. Firefox started faster, loaded pages faster, switched between tabs faster, JavaScript executed faster, downloads were faster, ...
Chrome developers were benchmarking for responsiveness: how long between the time you click and the user interface shows that something is going on. And that's all that end users actually see. Chrome showed its initial window faster (although it took more time until you could actually do anything with it), was slower at loading pages (but stopped its throbber earlier), slower at switching tabs (but the screen changed faster to show you that it was switching tabs), ...
Which ones were the "correct benchmarks" remains an open question, but it's clear which ones the users perceive/remember as being faster!
Of course, the better architecture that Chrome used meant that they eventually got faster at throughput, too, on computers that had sufficient RAM.
My company and I have no interest in supporting Firefox in the future and yes, I still feel betrayed when they dropped XUL. Many people did.
Even with WebExtensions, the Firefox extension review process is substantially lacking compared to the kind of developer experience I get with Chrome. The exact same extension takes a few seconds to release on the Chrome Webstore, vs. the laborious process I have to get through when releasing on Firefox.
The last straw for me was when the Firefox Extension reviewers asked me to provide a full-size package so that they can compile the extension themselves to compare if it matches the one that is submitted and if the output differs by some characters due to, let's say the order of the keys in a dictionary, though, it gets rejected. It does not matter if you have been supporting this extension for many years. It does not even matter if you are shipping the same code to Chrome and Firefox as well.
For companies that develop desktop-grade applications using web technologies, the only natural choice is Electron. It is stupid, for sure, because it forces developers to ship large binaries but what are the alternatives. QT? GTK? Please. The most popular non-native desktop applications are either based on Electron, Java, or some custom UI framework.
XUL had the chance to be the better cross-platform UI, and it was for some time until it was killed and with that, it lost an unmeasurable amount of developer time and future loss of productivity and a chance to be an actual alternative rather than a copycat.
As many others already pointed out, Firefox is Chrome, except that Chrome is still faster.
The demise of Firefox will hurt many at a personal level but frankly, it will hardly have any effect on the world because at the end of the day, WebExtensions are portable and Chrome is the pioneer in this space.
That might be very frustrating as a developer, but considering the amount of malware distributed on the Chrome Webstore this review process makes me want to use Firefox more.
I work in Security. This process produces no substantial results. They should invest into automation not some ill thought manual review process. This is part of the reasons why the Firefox extensions store is in decline. It is enough to look into the numbers to get the full picture.
In my experience, automating JavaScript analysis is a pipe dream. Maybe this could work if Mozilla forced add-ons to use TypeScript, but I feel that add-on developers wouldn't enjoy being asked to switch.
A great read. However, this part remains unfulfilled:
> we still haven’t taken the time to explain in-depth why we had no choice but to remove XUL-based add-ons.
I'm still waiting for an acceptable explanation. The author basically says "XUL was too vulnerable to security problems and crashes" but why couldn't it be left in? I think the real answer is a mix of "We don't have the developer resources (despite millions in revenue every year) to work on it, those resources are going to develop stuff like Pocket" and "We know better than the users, and the bug reports are tiresome, so let's lock it down and disallow people from using XUL addons"
This all happened due to pressure to compete with Chrome, but I think in doing so, Firefox lost it's uniqueness and became just another Chrome follower rather than a contender for web leadership.
> The author basically says "XUL was too vulnerable to security problems and crashes" but why couldn't it be left in?
There's an entire section called "The problems with XUL" that attempts to respond to this question (and another one called "The problems with XPCOM"). Do you feel anything is missing in either section?
As a developer, APIs changing and going away is a part of life. Apple deprecates APIs on macOS and iOS all the time. Even the concept of porting from an older to a newer OS is quite common.
Everyone rewrote DOS applications for Windows 3.x, then Windows 95, then Windows NT; Everyone rewrote applications for Apple II, MacOS classic, then OSX.
But, when I read this article, it exposes a clear need for powerful 3rd party browser APIs; even though the API may change between browser releases. (This, BTW, is what happens on Mac. If you develop a MacOS application, every year or so you need to tweak it.) Also, there's a clear need to install 3rd party plugins that can do things to screw up the browser. (This, BTW, is why desktop computers let you install whatever you want, and why you can sideload on Android.)
XUL in my memory is a kind of tragedy. It seemed to me to represent a future where GUIs could be programmed on any platform using an HTML-like language. Previously you had to individually write GUIs as applications, using languages like C++ or Java. Then web applications became more popular, and XUL seemed like it could sort of unify all the special applications some day. By roughly 2010, I think HTML5 was taking away some of the appeal of XUL, and at the same time the increase in popularity of smartphones led to a reversion to specially-built "apps". I hope some day there will be a popular "browser app" that everyone builds apps on.
> One of the topics that came back a few times was the removal of XUL-based add-ons during the move to Firefox Quantum. I was very surprised to see that, years after it happened, some community members still felt hurt by this choice.
Know your users. If I wanted to use chrome, I'd have used it. What made Firefox Firefox was its powerful addon eco-system. Now its just a poor chrome imitation.
2 can be explained by a feeling of betrayal. Mozilla's target user isn't me anymore, and quite frankly isn't most of the HN readership either. At least Chrome is the devil I know. Chrome's privacy "issues" are well known and documented, and are fairly trivially worked around. I'm not too worried about them claiming to be for privacy and then one day silently installing an addon that invades it. And that's not even getting into the addon mess. Or the other addon mess, where their nannying resulted in the worldwide breakage of all addons for all Firefox users.
3 can be explained for similar reasons as 2. I know where I stand with Chrome, and I already got more-or-less forcibly kicked out of the Firefox camp. There's a level of certainty here that doesn't exist with FF or whatever the new upstart browser is - I don't have this nagging fear that Google is going to do something with Chrome to make it more annoying or less useful. That is a very real fear I have with Firefox, and it's one that's been borne out repeatedly ever since addongate. If there's a choice between an option which gives the user more control and and option which gives the user less or takes some away, Mozilla usually picks the latter.
Not trying to armchair quarterback here, just speculating for entertainment
> Around this time, Mozilla started paying serious attention to Chrome. Chrome had started with very different design guidelines than Firefox:
> * at the time, Chrome didn’t care about eating too much memory or system resources;
> * Chrome used many processes, which gave this browser heightened security and responsiveness by design;
> * Chrome had started without an add-on API, which meant that Chrome developers could get away with refactoring anything they wanted, without this development tax;
as Chrome introduced their extension mechanism, they did it with a proper API, which could usually be maintained regardless of changes to the back-end;
Was it possible to do this inside Mozilla? Release a new browser with different branding that does not have these handicaps. Then, let the marketplace decide which browser to pick. If it won out, announce publicly that ongoing investment would be on the new browser.
There were discussions within Mozilla regarding whether this would be a good idea. Over the years, we released several smaller browsers for Android (Firefox Focus, Firefox Rocket). We rewrote a browser basically from scratch for FirefoxOS (which is now used in KaiOS, I believe).
I believe that if any of these browsers were ever to become big successes, a case could be made. For the moment, it doesn't look like this is happening.
I'd argue that the Firefox's implementation of the WebExtension standard (inspired by Chrome) has turned out to actually have the better API with Promises and a vendor neutral prefix.
That said, you're right that the independent competition made everyone better. Sadly with Chromium becoming the defacto web spec we won't get as much innovation.
This sounds like a pretty bad financial and strategic plan. So you suggest that Mozilla should have concurrently developed two browser engines, doubling the cost of its engineering while also competing with itself?
Servo was always a research project, and not a full browser replacement intended to compete with Firefox. As the article states, many components of Servo eventually ended up in Firefox.
> And then, as someone pointed out on reddit, I realized that we still haven’t taken the time to explain in-depth why we had no choice but to remove XUL-based add-ons.
> * very quickly, add-on developers realized that anything they did could break anything else in the system, including other add-ons and Firefox itself, and they often had no way to prevent this;
> * similarly, anything Firefox developers did could break add-ons, and they often had no way to prevent this;
> * also, some of the changes that Firefox needed to remain competitive with Chrome were going to break most add-ons immediately, possibly all add-ons in the longer term;
> * oh, and by the way, since add-ons could do everything, they could very easily do anything to the operating system, from stealing passwords to pretending to be your bank.
---
It's a really long article with lots of background and technical detail, so I felt it safe to include a larger summary of the basic points than I normally would.
> * oh, and by the way, since add-ons could do everything, they could very easily do anything to the operating system, from stealing passwords to pretending to be your bank.
So now there's way less things that add-ons can do, and it's supposed to be all peachy for Firefox users? Talk about competitiveness.
They're much better off starting with a highly restricted sandbox and extending that sandbox in safe ways when demand is demonstrated.
The alternative is letting their largely tech-naive user base install all kinds of add-ons under the illusion that it's no more dangerous than installing phone apps from an audited walled-garden app store.
Mozilla doesn't have the resources to audit all of the add-ons out there, and generalized automated auditing with a wide-open API would require solving the halting problem. (Accurately enumerating all reached states of a Turing-complete program would allow you to check if it reaches the halted state, thus solving the halting problem.)
Yes, but they are pitifully weak compared to the same addons back when they were implemented in XUL. It's not just because XUL was more free. WebExtensions as an API just lacks the scope for such enhancements. Mozilla essentially copies Google's API and they're very hesitant to make customizations, so major enhancement requests will just sit around for years without traction. I'll list out a few major issues with the current API for the sake of example:
* No native hotkeys.
Ok, fine, there are technically native extension hotkeys, but they break so often that nobody uses them. Even if they were fixed, the bindings are arbitrarily limited to two-modifier combinations.
Instead, you're stuck hacking around the limitation by injecting hotkeys into each individual page via JS. If the page you're on isn't a normal webpage (new tab, 404, PDF...), you're out of luck. It's mouse time.
Imagine the pain of writing and rolling your own high level key binding API, now imagine the additional memory/compute from running that in every single tab instance. This is already a huge mess that makes any tab extension a second-class experience.
* UI extension is hopelessly neutered
WebExtensions basically have 3 main places where you can render UI: solo pages, a toolbar popout, and the sidebar. Of these three, only the sidebar is a permanent, persistent place that works for the purposes of a tab extension. Unfortunately, the sidebar is hopelessly neutered. The sidebar is shared between all extensions AND the native bookmark/history managers, so bad news if you need it for something else! Since it's shared, you can't control the size/position programatically (Oh yeah... and the manual resize threshold is limited to about 1/6 horizontal screen width).
To add insult to injury: the sidebar steals page focus, so I hope you enjoy clicking back into the web page every time you interact with the sidebar UI via mouse! This dovetails nicely with point #1. There's no way to bind a key to your extension's sidebar. That means you can't toggle your tab bar (a la F11). It also means you have to fish for your mouse, fiddle with the toolbar, then switch sidebar panes any time you lose the sidebar for any reason.
Imagine the pain of supporting an extension that literally does nothing unless you get your users to dig into the toolbar and enable a little-known UI element. Now... imagine the pain of asking them to do that, repeatedly, whenever it goes away.
* Horizontal tab bar is a pipedream
Your control over actual tabs, in the actual tab bar, is incredibly limited. If you're not outright hiding the tab bar and replacing it with a sidebar hack, it's basically guaranteed to be a mess. You cannot style nor group tabs programatically. All you can do is hide or reorder them, which is a pretty bizarre decision, imo...
The best that anyone can do for non-overhaul extensions, like "tab grouping", is stashing the UI away into the toolbar popout menu. I hope it's fairly obvious why this isn't an ideal way to present that information, especially when you consider that it's a focus-stealing modal.
> also, some of the changes that Firefox needed to remain competitive with Chrome were going to break most add-ons immediately, possibly all add-ons in the longer term;
Sad part is that we lost extensions and Firefox is still slower, glitchier than Chrome.
Note: This is a comment I wrote to another article in HN and it still holds today:
No. Just, no.
I want to share something that I experienced very recently.
I use Firefox and Chrome (just for using Taskboard) at work. I also use Firefox at home. Both systems are Debian. The perceived browser speed was Chrome (Work) > Firefox (Work) > Firefox (Home). I always thought it was about DNS resolution, so I started running DNSMasq at home on an OrangePi Zero but, it didn't make much difference.
Two days ago, my home ADSL modem suddenly died. I replaced it with a more modern version and everything about speed has changed. Now The speed of Firefox at home is equal with the speed of Chrome at Work, Firefox at work is slightly behind.
It can be said that Firefox is much more sensitive to network parameters like DNS response times, but its rendering engine and other capabilities are not behind Chrome.
As an avid Firefox user, the performance difference between the Javascript engines in Chrome and Firefox are always obvious to me.
Firefox's network code, render pipeline, and everything else that gets the document to the screen is either just as fast or even faster than Chrome. However, the Javascript engine leaves something to be desired; the trend to make everything an application has ruined the performance of many sites.
There's also downsides to the way Firefox protects your privacy. If you enable the default privacy blocking, some resources fail to load on websites, making many websites load fallbacks or lag while they're waiting for their ad script to initialize.
Finally, I've noticed Firefox has significant performance issues in video decoding compared to Chrome. This manifests itself as memory leaks and some tabs being frozen (every tab within the same browser subprocess, basically) and can be resolved by killing the process that's been messed up, but it's still an issue for normal use.
All in all I prefer Firefox, but there's still plenty of ways it can catch up to Chrome. If your work involves a lot of web applications, there's no denying that your experience in Chrome will be quicker.
All websites that heavily rely on Javascript just work better on Chrome for me. Google products, OSM, streaming sites, chat applications, they just all work quicker and smoother on Chrome. Even my own code seems to run into more performance caps on Firefox depending on the behaviour it exhibits.
On plain websites, there's no real difference. When it comes to (messy) JS, problems pop up more in Firefox than in Chrome.
I don't blame the Spidermonkey devs for this, of course, because people just need to write better (less) JS. However, in practice, you do see the difference when you try out Firefox.
Thanks for your answer. Being able to discuss these things feel good.
> However, the Javascript engine leaves something to be desired; the trend to make everything an application has ruined the performance of many sites.
I'm pretty bitter about "everything is an application" trend though. Coming from the original web, limited by 56K days creates a lot of "old man yells to cloud" moments, performance wise. However, as a Linux user, I suspect not all of the performance penalty comes from the JS pipeline. Accelerated rendering of webpage is severely lacking in Linux (especially with nVidia proprietary drivers).
The graph animations are smooth in Chrome & Firefox for Windows but, not in Firefox for Linux. I think rendering engine is fine, JS is more than good enough, but HW acceleration in Linux needs attention.
> There's also downsides to the way Firefox protects your privacy. If you enable the default privacy blocking, some resources fail to load on websites, making many websites load fallbacks or lag while they're waiting for their ad script to initialize.
It may be but I didn't notice anything to be honest. I'll look out for this.
> Finally, I've noticed Firefox has significant performance issues in video decoding compared to Chrome. This manifests itself as memory leaks and some tabs being frozen (every tab within the same browser subprocess, basically) and can be resolved by killing the process that's been messed up, but it's still an issue for normal use.
I don't experience anything similar in Firefox. Sometimes I leave Youtube open for weeks (because, long music mixes) and nothing stutters or goes awry. Sometimes a tab consumes too much resources (something like reddit or, HN) and it creates input lag while writing into textboxes like this. Everything recovers when I kill the offending tab. Similarly watching 2K and 4K videos over youtube doesn't tax my system at all. Everything is gracefully HW accelerated OTOH, picture in picture implementation of Firefox is so much behind that I can see the frame rate drops below 15FPS most of the time, so it's unusable. I guess, it the FF could HW accelerate everything, the problem will solve itself.
All in all, Firefox has some missing parts and needs some serious work in these parts and FF people looks not very interested in these parts (I'm not very firm on this opinion. This is how it looks from here).
> I'm pretty bitter about "everything is an application" trend though. Coming from the original web, limited by 56K days creates a lot of "old man yells to cloud" moments, performance wise. However, as a Linux user, I suspect not all of the performance penalty comes from the JS pipeline. Accelerated rendering of webpage is severely lacking in Linux (especially with nVidia proprietary drivers).
I totally a agree.
> It may be but I didn't notice anything to be honest. I'll look out for this.
The worst offender are some AMP sites; they try to use the Google CDN for whatever resource (probably fonts or CSS) and when that fails, wait for the fallback.
> Everything is gracefully HW accelerated OTOH, picture in picture implementation of Firefox is so much behind that I can see the frame rate drops below 15FPS most of the time, so it's unusable.
Interesting. I don't have much trouble with PiP and such, only the memory issues. I suppose it might just be a difference between hardware, drivers and OS/system config.
>> * also, some of the changes that Firefox needed to remain competitive with Chrome were going to break most add-ons immediately, possibly all add-ons in the longer term;
This is probably the most important point. The other points apply to almost any software that supports addons, including emacs, vim, zsh, etc. and they're not really an issue.
>> * very quickly, add-on developers realized that anything they did could break anything else in the system, including other add-ons and Firefox itself, and they often had no way to prevent this;
So they're careful. Any add-on that breaks other stuff doesn't really get adopted. Emacs shares the same namespace for everything. Addon developers just namespace their stuff by putting a prefix on their identifiers. It's not really an issue even for them.
>> * similarly, anything Firefox developers did could break add-ons, and they often had no way to prevent this;
So don't change Firefox so drastically. Well, I'd say it's nice for software to be stable, but web browsers are a good exception to that. If Firefox didn't try to keep up with Chrome, Chrome would probably have greater dominance.
But yeah, other software would just be more stable. When a change needs to be made, the benefit is weighed against the potential of breaking addons, but I imagine that's probably OK with addon developers as long as the change was reasonable.
>> * oh, and by the way, since add-ons could do everything, they could very easily do anything to the operating system, from stealing passwords to pretending to be your bank.
Most times, addons are almost like any other program, and should be judged accordingly before installing. I imagine even after the restrictions were placed on addons, they're probably still capable of quite a bit of malice.
> Emacs shares the same namespace for everything. Addon developers just namespace their stuff by putting a prefix on their identifiers. It's not really an issue even for them.
I use and love Emacs (Spacemacs), and I am probably never going to move to another editor.
BUT as someone who maintains a Spacemacs config, no, Emacs addons break each other all the time. It's not just a namespacing problem, it's which events you're hooking around or interrupting, it's which system features you're changing that other addons rely on.
This kind of organized chaos works out OK in Emacs because I can read the source code of the offending Spacemacs layer or script and wrap around it to get it playing nicely with the rest of my setup. Emacs has very good debugging tools built into it, and you can hack on the editor in the editor. It also has a fairly decent community of people online who will help you debug configs as long as you're not being too annoying about it. This all ends up being pretty important, because you are going to need to debug configs.
Emacs expects you to be a power user that knows how to program, and if you are a power user that knows how to program, there are advantages to that. But even with those advantages, the sheer amount of time I've wasted getting EXWM to play nicely with other workspace addons...
I just think there's benefits and tradeoffs to both approaches, and I wouldn't be so quick to dismiss the engineers who decided that their users shouldn't need to learn how to program to keep a functioning set of addons running in their web browser.
My question is then: where's the hackabale power user browser implemented in something like Common Lisp with a REPL, hot swap debugging, and built in disassembly tools?
And this is (one of the reasons) why it's wildly important that we have a diverse browser ecosystem rather than all building minor forks of Chromium.
And this is also why (disingenuous as they often are), some of the "web is too complicated" arguments can't be completely dismissed, because it is true that building a secure browser that's safe to use is a gargantuan task.
And this is also why it stinks that the Servo team got gutted, because Servo was shaping up to be an interesting new low-level embedded engine in that space.
Both sides are true. I understand completely why Mozilla went the route they did, and I agree with their decision to do so, and I also sympathize completely with the people who want to be able to live-hack on their browser in their browser. I want the ability to do that too.
But I think the only way to solve that is to have more browser diversity... somehow. I also don't want Firefox to be unusable for nontechnical users. I need a secure, reasonably private browser that's not based on Chrome that I can recommend to nontechnical friends and family.
Trouble is not only the complexity of a web browser (and security thereof) but that Google's "living standard" is a constantly shifting target. Even a company like Microsoft couldn't keep up with it and gave up. So long as Google is in charge and has infinite* resources to throw at it, nobody else is ever going to be able to keep pace.
Apple works around that by not really trying to keep up. It implements features in its own time (or else some third party contributes code to WebKit). But iOS gives Apple a captive audience which means it has much more freedom to be "slow" compared to Google. As much as I might philosophically dislike their policy of only allowing their own web engine on iOS, it is the only thing keeping WebKit alive as a major alternative.
Apple and Microsoft both have resources to dedicate as much man/machine-power as Google does for their browsers if they wanted to. They just don't want to play the neck-and-neck game any more. MS has opted to simply use Chromium while Apple as you say goes at its own pace. But they do have the capacity to match Google if they choose to, given some ramp-up time.
>I also don't want Firefox to be unusable for nontechnical users. I need a secure, reasonably private browser that's not based on Chrome that I can recommend to nontechnical friends and family.
My sister uses Firefox just fine, she doesn't know how to mess with addons.
There are efforts, and there are things you can run, but I wouldn't personally recommend doing so. I am very paranoid about browser security, and I (frankly) don't trust smaller browser projects that aren't highly vetted by lots of people.
That's an entirely separate conversation.
My opinion is that it ends up being simpler and safer at the end of the day to just wrap the entire Firefox application in an Emacs buffer and then intercept keypresses to that buffer. But you do lose out on a lot of stuff by doing that; I'd love to have tighter integration.
eww doesn't work very well yet. Try it for fun only. And it's slow. Pretty certain it does cookies but not js.
I think there's an emacs web browser which delegates the actual mechanics to something external, and only acts as a front end for display/interaction. Never tried it.
In the latter EAF isn't a web browser despite what it says. Have a look at the others. Piggyback browsers aren't going to be sophisticated, that's just how it is.
> I think the key is that I don't use any deeply intrusive packages
Sure, but if you're not interested in using deeply intrusive packages or addons, then why does the sandboxing and forced separation between addons matter?
I can keep a clean Firefox config if I don't install addons that do anything too interesting, but if I don't install addons that do anything too interesting then I'm also not really going to be affected very much by the move from XUL to webExtensions. I think the core of the debate is about the intrusive packages, not the surface-level ones.
The only reason for Emacs to embrace the more dangerous kind of "everything is editable" levels of customization that people are advocating for within Firefox is so that we can implement stuff like Evil, EXWM, sidebar previews, embedded GTK apps, etc... Those are the power-user selling points of Emacs that keep me hooked on the platform.
> So they're careful. Any add-on that breaks other stuff doesn't really get adopted.
This wasn't true at all. A lot of popular addons interacted with the browser XUL in incredibly intrusive ways. In particular, addons which altered the browser's tabbed browsing interface and/or behavior (like the various Tab Mix extensions, as well as Tree Style Tabs) tended to do so by making radical modifications to XUL, which would often break other extensions which interacted with tabs.
> Addon developers just namespace their stuff by putting a prefix on their identifiers.
That was not standard practice, unfortunately. Conflicts between extensions were commonplace; it was a rule of thumb to avoid installing multiple extensions which interacted with the same browser feature.
> So don't change Firefox so drastically.
This would have meant effectively freezing most UI development, to say nothing of more ambitious projects like e10s (multiprocess browsing). It would have led to the inevitable death of the project by stagnation.
> Most times, addons are almost like any other program, and should be judged accordingly before installing.
You heavily overestimate the degree of scrutiny that users applied to extensions. The fact that they could be installed from a web interface made users treat them very casually.
> I imagine even after the restrictions were placed on addons, they're probably still capable of quite a bit of malice.
XUL-era extensions had vastly more power than WebExtensions. They were equivalent in power to native executables -- they could run native code, read/write any file on the system, and communicate with any host, all without confirmation -- and there wasn't even any framework to allow developers to voluntarily restrict their power, because they ran in the same context as the rest of the browser chrome.
> You heavily overestimate the degree of scrutiny that users applied to extensions.
I apply scrutiny in the form of very carefully vetting the author's identity and reputation. At the end of the day that seems to be a fairly common and reasonably effective approach.
> XUL-era extensions had vastly more power than WebExtensions. They were equivalent in power to native executables
That was an important feature, not a bug (IMO). Sure WebExtensions are nicely sandboxed away from the OS, but the threat posed by a malicious version of uMatrix or Dark Reader is nonetheless difficult to understate.
Certainly many users made poor decisions. Certainly there were valid technical issues at play. But let's not pretend that all users are irresponsible or that there weren't serious drawbacks to what was done in terms of lost functionality. Some of the modifications I made use of still haven't been replicated in WebExtensions due to lack of ability (AFAIK). The only solution I'm aware of would be to patch the browser myself and recompile it, which is an _incredibly_ high barrier to entry (and that's before the ongoing maintenance burden).
There's a reason that phishing is the go-to infosec attack vector. It's because we still blame users for being tricked into doing things they shouldn't, rather than taking the time to build systems that prevent such vectors from working.
I'm happy that extensions no longer have such wide-reaching access to the system. Whatever we lost in power-user tinkerability isn't worth the high personal cost that the malicious extensions would have on the lives of unsuspecting users.
I don't think this sort of security trumps everything else approach is a valid line of argument. Surely there are tradeoffs to be made, and surely one size doesn't fit all.
As to phishing in particular, I don't agree that the issue is a lack of willingness to design resistant systems or a misguided assignment of blame. I think it's because solving that problem at scale in the real world is (or at least was) legitimately difficult. The vast majority of people in the world don't carry a YubiKey on them and probably won't any time soon. There are even users in the US that still don't have reliable access to a mobile phone! A product that doesn't work for the actual users simply isn't viable.
>There's a reason that phishing is the go-to infosec attack vector. It's because we still blame users for being tricked into doing things they shouldn't, rather than taking the time to build systems that prevent such vectors from working.
Such system was already built in the bronze age: Troy.
>Any add-on that breaks other stuff doesn't really get adopted.
Yes it does, Firefox is a mainstream browser not a niche product used by experts. Most people couldn't even figure out which of their fifty extensions was causing issues. So they just used Chrome.
This is exactly it. Normal users don't think "Huh firefox is crashing, I'm going to disable addons one by one to work out if one of them is the cause" They just think "Wow, firefox is super buggy, I'm using chrome now" And then every time they see firefox mentioned online they leave their comment about how its super buggy and crashes all the time.
I just had an idea: to install an extension require authentication by a one time random password, show the password in a modal window without ability to copy, the user will have to remember the password and type it into a field. The password length is equal to the number of installed extensions, so to install 50th extension, you need to type 50 character password.
> But yeah, other software would just be more stable. When a change needs to be made, the benefit is weighed against the potential of breaking addons, but I imagine that's probably OK with addon developers as long as the change was reasonable.
We thought that too, for a time, but eventually, we had to realize that we were burning out our add-on developers.
Changes and maintenance cost money and time. In this case, they deemed it to not be worth the expense to resolve the potential security issues (which can never be truly resolved).
Good. That's a feature. I install addons. It's not a site i visit with no consideration.
This is the same thinking of apple. People install random apps so let's restrict apps to the point the user cannot have a text editor on their phone! meh! This is all dumb!
Now it is impossible to have the choice to install an addon for tweaking hidden options. Everyone should live with the crap that is about:config and user.js (or only about:config, because they thought user.js too dangerous on mobile too!)
I trust an open source browser by random people, why not an open source addon that gives me the functionality i need?
Browsers that split off because of the killing of XUL and establishment of the Firefox walled garden continue to operate using XUL and the giant (and still improving) ecosystem of add-ons that defined what Firefox was. There are no problems even with a ten thousandth of the resources that Mozilla has.
Mozilla removed XUL and all the power features because they were incompatible with building a chrome clone that could protect users from themselves. They did this because market share became more important than features and the vast majority of people don't want or even understand that their browser can be customized.
No. But I can assume that you weren't paying attention back when all this happened rather than this rewrite of history. Also, did you even read the article? It literally follows the thread I laid out but then tries to justify itself.
ie, "Around this time, Mozilla started paying serious attention to Chrome."
It's likely you'll never understand why so many former Firefox users are still angry about you killing Firefox and replacing it with a user-hostile chrome clone then.
But just in case you do actually care and aren't just trying to re-write history as you see it: It's because of the "fixes" you describe were all making things easier, faster, and less powerful. Those aren't what Firefox's old userbase wanted. Firefox was the customizability. Now FF is just another safe javascript engine with a GUI.
The forks of FF that remained FF still exist just fine on a fraction of the resources Moz has despite all your complaints of unmaintainability.
> Those aren't what Firefox's old userbase wanted.
What some vocal subset of Firefox's old userbase wanted. I understand the frustration (some tools I used also broke in the transition), but for me the tradeoff of a faster and less crashy browser is easily worth it (EDIT: this is of course assuming full multi-process was indeed not realistic while maintaining XUL). And plenty Firefox users barely use add-ons.
The XPCOM-based extension mechanism was mostly dropped (we still use it internally)
See, that's the rub. Many of us would choose to have add-ons that break every time the browser updates, or delay browser updates until our mission-critical extension is updated. You didn't give us that choice though. You said "do it the way we want you to do it or piss off." Looking at Firefox's 3% market share, most of us chose the latter.
Our experience is that add-on developers didn't like that. Only the few add-on developers that actually made money from their add-ons could afford to rewrite their code every 6 weeks.
A couple of years ago I swore I would never leave ff, but they decided to just neuter the add-ons and remove most of them. So I didnt think twice. Moved to waterfox, and then to Palemoon. I'm happy.
I'm sad they're losing, but they need to be adults about it and do what needs to be done. I and many others are waiting to go back as soon as they fix things.
This comment is seemingly a reaction to the post's title and doesn't address (or even acknowledge) the contents of article. Do you disagree with the technical rationale the author has presented?
The content of the article does not really make a technical argument. It just says "XUL can not be fast, because I said so". The code of Firefox has always been a historical grown mess with a lot of loose ends that need to be entangled. I'm convinced that a XUL version can be made fast as well if you spend the appropriate amount of engineering hours on it.
Actually, it shouldn’t be surprising at all since people lost a lot of useful functionality that still do not have replacements today. Users were not stuck on XUL as a technology. They cared about functionality and power user functionality!
I’m using mainline Firefox and not some fork that still supports XUL addons, but I still miss not having good replacements for:†
* Tab Mix Plus (I haven’t seen any replacement for this; and if you haven’t used this in the XUL world, you wouldn’t know the value of it)
* Lazarus (form saver)
* Session Manager (no, other session saving extensions still feel iffy to me)
For reasons I haven’t delved into, these extensions cannot live in a WebExtensions world today. So yes, I’m one of the people hurt by the choice not of removing XUL, but not providing alternatives even several years later.
> The main drawback is, of course, that WebExtensions do not give add-on developers as much power as the promiscuous extension mechanism. I hope that all the power that add-on developers need can eventually be added to WebExtensions API but that’s something that takes engineering power, a critical resource that we’re sorely lacking.
I don’t have a lot of hope since years have passed with progress in making some more addons work with WebExtentions but not really close to being there for other addons. Though the Firefox team has said it’s currently not planning to implement Manifest V3, if and when it does (and depending on how it does), that could potentially make uBlock Origin obsolete. That would be a much larger blow to the users.
†: Please let me know if you have suggestions for great replacements for the first two extensions.