8 ms·

Why did Mozilla remove XUL add-ons? (2020)

111 points by imiric 4y ago

deleted 4y ago
[deleted]
cuteboy19 4y ago
Such a post at that time would have greatly improved people's response to the change. Instead what we usually get is a PR sanitized gobbledygook which occupies space without speaking much at all. Now a similar thing is happening with Firefox Android and their extensions. Firefox can easily run most extensions but it's hidden behind a config in a canary release of the browser. No doubt there are some good reasons for it but we simply do not know. Ultimately this is a fault common among almost every product designer. They refuse to explain their decisions fearing (perhaps justly) that they may be proven wrong. Many such cases
- wolpoli 4y ago
  The product designers don't realize that a lot of the backlash comes from the technically-minded audience, and that their usual approach of highlighting user benefits only further fuels distrust among that vocal community.
- commoner 4y ago
  > Now a similar thing is happening with Firefox Android and their extensions. Firefox can easily run most extensions but it's hidden behind a config in a canary release of the browser. No doubt there are some good reasons for it but we simply do not know. Ultimately this is a fault common among almost every product designer. They refuse to explain their decisions fearing (perhaps justly) that they may be proven wrong. There were no good reasons for Mozilla to restrict extensions on Firefox for Android. It was a stupid decision that alienated Firefox's user base on Android with no real benefits. However, Mozilla has finally listened to the negative feedback and custom add-on collections are now available on Firefox Beta for Android: https://www.ghacks.net/2022/10/20/firefox-beta-for-android-now-supports-custom-add-on-collections/ https://www.ghacks.net/2022/10/20/firefox-beta-for-android-n... Mozilla also said they would start working on WebExtensions on Firefox for Android this year. The goal is to have feature parity with desktop Firefox, which includes retaining the Manifest v2 features that uBlock Origin uses: https://blog.mozilla.org/addons/2022/12/15/new-extensions-available-now-on-firefox-for-android-nightly/ https://blog.mozilla.org/addons/2022/12/15/new-extensions-av... While Mozilla has made numerous missteps in the past, it looks like they're finally moving in the right direction.
  - m-p-3 4y ago
    What also annoys me is they disabled about:config on the Firefox for Android Stable release..
  - yjftsjthsd-h 4y ago
    However, Mozilla has finally listened to the negative feedback and custom add-on collections are now available on Firefox Beta for Android Anything to avoid putting a useful feature in a stable release or making it convenient, I suppose...
  - its-summertime 4y ago
    The API being unfinished, meaning web extensions could fail in random, unexpected ways, sounds like a good reason to me?
    - cuteboy19 4y ago
      No reason why it can't be hidden behind a WARNING:MAY BREAK or about:config. But they implemented it in such a roundabout manner. Anyways the issue is not the decision but rather the communication about it. Ideally a dev post about this could have satisfied a lot of people but they chose to go with the PR soup method. It's not even that these are exclusive, include a link to dev post in the soup
      - its-summertime 4y ago
        https://blog.mozilla.org/addons/2020/09/02/update-on-extension-support-in-the-new-firefox-for-android/ https://blog.mozilla.org/addons/2020/09/02/update-on-extensi... and https://blog.mozilla.org/addons/category/mobile/ https://blog.mozilla.org/addons/category/mobile/ ? > We looked at add-on usage on Android, and made the decision to start by building support for add-ons in the Recommended Extensions program that were commonly installed by our mobile users. Enabling a small number of extensions in the initial rollout also enabled us to ensure a good first experience with add-ons in the new browser that are both mobile-friendly and security-reviewed. And progress is on the MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
imbnwa 4y ago
I remember using Songbird in the late 00s, a music player built on top of XULRunner, as well as a twitter client. They're not exactly 1-to-1, but there's something funny to how Electron provides that browser-based platform for desktop apps now.
- Semaphor 4y ago
  It's even mentioned in the article. I think I tried it back then, but preferred foobar2k.
  - deleted 4y ago
    [deleted]
- notRobot 4y ago
  I remember getting a fork of it, Philips Songbird, with an MP3 player and using it for a few years on a Windows XP machine. Worked much better than iTunes, and I actually kinda miss it a lot.
  - TedDoesntTalk 4y ago
    I worked hard to keep my addon compatible with Songbird.
- giantrobot 4y ago
  I was partial to Flock, another XUL browser. It integrated a bunch of of social media APIs of the day in interesting ways.
  - thakoppno 4y ago
    I remember Flock fondly. Any recall why it didn’t work out? Did Firefox’s ascendency stall out Flock?
    - giantrobot 4y ago
spankalee 4y ago
> Firefox developers started porting components from XUL to HTML5 More specifically, Firefox's UI wasn't just ported to HTML5, but to web components. This means much of two of the three major browsers (also parts of Chrome and Chrome OS) are using web components for the UI. Part of what enabled a move from XUL was that HTML finally got custom elements, where XUL/XBL had had custom components for a long time.
- chrismorgan 4y ago
  I don’t believe that Web Components had anything to do with it at all. When you control the scripting environment, and would be instantiating in scripting rather than in serialised markup, Custom Elements are one of the more superfluous features of the web platform: everything you can do with them, you can do every bit as effectively without them, at no meaningful cost or cost saving. The point where things get a little more interesting is when you introduce Shadow DOM, because then you do have genuine capabilities that can’t be expressed in other ways (though whether you want to may be another matter). But the real kicker, in my assessment and conclusion, is that both of these features landed after the migration from XUL to HTML began. (Not all that long after, and they have since been used variously, but the moving initiatives began before they were available.)
  - bgrins 4y ago
    I worked on this project - Web Components had a lot to do with it. It's true they weren't feature complete in Firefox when we started the project (notably missing Shadow DOM) - but the first migration from late 2017 was XBL->Custom Element (https://bugzilla.mozilla.org/show_bug.cgi?id=1500626 https://bugzilla.mozilla.org/show_bug.cgi?id=1500626), and we used the migration project to inform performance and feature work for Web Components within Firefox. We could have converted the bindings to JS modules (and we did plenty of that too), but Web Components were key because they allowed us to migrate in-place with near API compatibility rather than rewriting the UI. I have a post at https://briangrinstead.com/blog/firefox-webcomponents/ https://briangrinstead.com/blog/firefox-webcomponents/ with more detail on that point.
MollyRealized 4y ago
I have to say, I miss Keyconfig SO badly.
- metadat 4y ago
  I'd never heard of KeyConfig. To save others the effort: It was a keyboard customizer XUL extension for Firefox and Thunderbird. http://kb.mozillazine.org/Keyconfig_extension http://kb.mozillazine.org/Keyconfig_extension
- ashtonabc 4y ago
  Keyconfig and other legacy extensions are still available for modern Firefox with a modified userChromeJS: https://github.com/xiaoxiaoflood/firefox-scripts/tree/master/extensions/keyconfig https://github.com/xiaoxiaoflood/firefox-scripts/tree/master...
- cycomanic 4y ago
  For thunderbird there is tbkeys which is the spiritual successor. I use it to implement mutt like keybindings.
dang 4y ago
Discussed at the time (of the article): Why Did Mozilla Remove XUL Add-Ons? - https://news.ycombinator.com/item?id=24231017 https://news.ycombinator.com/item?id=24231017 - Aug 2020 (336 comments)
sabellito 4y ago
I might be one of the dozens of people in the world who actually shipped production software using XUL. It's a generic admin software for recruiting companies, still has some 200 daily users. At the time, in 2004, PrototypeJS was all the rage, and XmlHTTPRequest didn't exist yet. XUL helped us ship a more rich user experience without extreme pain. The whole thing was even a pseudo-SPA, using iframes everywhere, which we also used to fetch extra data for some pages without navigating.
- fzzzy 4y ago
  XmlHTTPRequest existed, it's just that Firefox hadn't implemented it yet. IE had it since 1999.
  - sabellito 4y ago
    You are, of course, correct!
  - unscaled 4y ago
    XMLHttpRequest was available since Firefox was called Firefox[1], and it should have been at least partly functional in 2002 when Phoenix 0.1 (the predecessor to Firebird and Firefox) was released. In 2004, Firebird just got renamed to Firefox (on version 0.8) and Safari implemented XHR. Opera and Konqueror would implement it in 2005. The main issue obstructing the use of XHR was not browser compatibility. Internet Explorer still had 95% market share, and almost nobody cared about compatibility with other browsers then. The issue was mostly about awareness, and lack of proper tooling. The term AJAX was only coined in 2005, so the technique of using XHR to reduce page refreshes and improve page responsiveness didn't even have a name. It was used here in there by savvy web developers, but it wasn't systematic. Before 2005, very few websites were built entirely on XHR. It was out there, lurking in the shadows, but not transforming the way web was done yet. Outlook Web Access (for which XHR was developed) is an obvious mention, but the first site that got XR popular was probably Gmail Beta, in 2004. I think a lot of developers suddenly wanted to replicate it, and with the popularization of AJAX in 2005, learning resources become easier to find, libraries and frameworks got developed to make its usage easier (anybody said jQuery?) and so on. [1] See: https://bugzilla.mozilla.org/show_bug.cgi?id=237606 https://bugzilla.mozilla.org/show_bug.cgi?id=237606. Interestingly enough, this bug report was about trying to access an XPCOM component from a web page, not about an incompatibility with whatever IE was doing. IE didn't even have XPCOM after all!
superkuh 4y ago
You can still use XUL based add-ons. You just can't do it in the chrome-in-spirit modern Firefox. There are plenty of great Firefox forks still maintained to this day that support XUL add-ons. And despite Mozilla's attempts to stop it users have scraped and collected together all the old addons in various archives. I'm not saying this is a good solution for facebook/youtube/twitch/etc users that treat their browser as an OS to run applications. It's not. But if you surf with javascript disabled and tend to only use actual websites written in HTML it's still viable. (the html web still exists, it's just not as loud and attention grabbing as the megacorp javascript silos)
- smabie 4y ago
  who actually surfs with js enabled? gotta be less than 1%
  - throwaway290 4y ago
    You wouldn't know because none of the trackers would fire...
    - dathinab 4y ago
      That is a common misconception. There are multiple ways to track people with similar precision as common JS trackers without using JS. When it comes to simple statistics there are even far more ways. I would go a step further and say that JS tracking is mostly limited to a certain very small subset of people which making it likely less then 0.01%, potentially even much less then that. Most of the web is inaccessible without JS including many of the most widely used websites and most users don't even understand why not using JS could do anything good. Or understand what JS is. Expecting any not completely irrelevant non-JS browser share is just not realistic.
      - throwaway290 4y ago
        This is all beyond the point which was that stats about no-JS users are almost nonexistent. You can keep saying "but there can't be many people using web without js" but they literally fly under your radar. > There are multiple ways to track people with similar precision as common JS trackers without using JS. And almost no one uses them. > I would go a step further and say that JS tracking is mostly limited to a certain very small subset of people which making it likely less then 0.01%, potentially even much less then that. I barely see a project that does anything except Google Analytics at default settings with a script tag. > Most of the web is inaccessible without JS including many of the most widely used websites "Most of the web" actually works. Some of the popular ones don't but Wikipedia/Google/Amazon/Facebook (to a degree) are OK. All latest front-end frameworks are built to deliver working HTML with minimal JS instead of SPAs. > most users don't even understand why not using JS could do anything good. Or understand what JS is. There was a time most users didn't even understand why not using IE could do anything good or understand what a browser is. Times change.
jerrysievert 4y ago
I was very sad when XUL disappeared from Firefox - I had written a serial plugin in c++ via XPCOM, which had allowed us to more easily test and deal with firmware updates in the hardware we ran, and having XUL in Firefox meant for fairly quick and lightweight touchscreen applications that could be shipped to customers with very low hardware requirements, nothing like you'd need for electron today. these were for point-of-decision kiosks, and were so easy to build and maintain, truly a great era.
2h 4y ago
Firefox Android has been awful for a while now. You cant sideload extesions on Android for at least two years now, with the only workaround being use an older Firefox: https://github.com/mozilla-mobile/fenix/issues/20736 https://github.com/mozilla-mobile/fenix/issues/20736 then they close the issue and move to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1796184 https://bugzilla.mozilla.org/show_bug.cgi?id=1796184
- tredre3 4y ago
  This has nothing to do with the XUL addons discussed in the article.
- binarysneaker 4y ago
  But you can run Firefox Nightly and use a custom extensions list. This is how I have all my regular extensions running great on Android.
  - 2h 4y ago
    that requires registration on AMO. I should not have to do that to install an extension that I WROTE
figital 4y ago
Being able to script buttons in my browser's toolbars is a feature I miss (circa the Jetpack era of Firefox). It greatly increased my productivity. Doing some of this now on my Linux desktop using jgmenu ... it's not a browser though ... it's a floating data-driven start menu. Very fun.
schneems 4y ago
It’s been over a decade since I touched a Firefox addon and I still remember their ghostbusters easter-egg/joke. Went something like: keymaster/gatekeeper/thereisonly.xul
- chrismorgan 4y ago
  http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xu...
- bitwize 4y ago
  Also explains why their in-browser debugger was called Venkman.
qwertox 4y ago
XUL was great. There was this tabs extension which allowed to have multiple rows of tabs open and even more rows accessible through scrolling with the mouse wheel. Or another one which allowed to tile pages in one browser window.
- 51Cards 4y ago
  I still miss TabMixPlus in my daily browsing. Haven't found a tab manager since that can match what it did for me.
  - yoasif_ 4y ago
    You could try TabMixPlus: https://github.com/onemen/TabMixPlus https://github.com/onemen/TabMixPlus
pmoriarty 4y ago
I miss Pentadactyl
- ZekeSulastin 4y ago
  Have you given Tridactyl a shot?
  - mariusor 4y ago
    Tridactyl is nowhere near as usable as Pentadactyl was, and its injection of JS/CSS in every page you visit is very, very intrusive. Sadly it's the only option that is usable for me at the moment, but I think everyone - including its devs - would agree that it can never reach the same level to Pentadactyl due to not having access to the browser's chrome.
    - bovine3dom 4y ago
      About five years ago we had agreement in principle with Mozilla to extend the web extension API to accept keypresses from anywhere, provided that someone did the work to write that API. We started it [1] but lost interest because we think Tridactyl works mostly fine without it (press ctrl+, anywhere to get back to Tridactyl) and I have always found more urgent things to improve. I'd be happy to help anyone who wanted to pick it up, but a lot of the political work of persuading Mozilla that such an API would be useful would need to be restarted since most of the people we persuaded in the past have now left Mozilla. [1]: https://github.com/tridactyl/keyboard-api/ https://github.com/tridactyl/keyboard-api/
- michaelmrose 4y ago
  https://github.com/tridactyl/tridactyl https://github.com/tridactyl/tridactyl
cultureulterior 4y ago
There was no excuse, they should just bring xul back
- michaelmrose 4y ago
  https://yoric.github.io/post/why-did-mozilla-remove-xul-addons/ https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... People wanted a faster, more secure, multi-threaded experience. > Note: Having read in comments that some users apparently do not care about security, let me add that being secure is a really, really important point for Mozilla and has been since the first day. Regardless of add-ons, not having security means that an exploit is eventually going to show up that will steal user’s passwords and use them to steal their bank accounts – and that exploit will get sold around and will soon show up everywhere. Firefox developers fight this threat daily by all sorts of means, including code reviews, defensive programming, crash scene investigations, several types of sandboxing, static analysis, memory-safe languages, … Consequently, for Mozilla, if a feature prevents us from achieving great security, we always pick security over features. You should read the link.
  - cultureulterior 4y ago
    I did. The security argument is a poor one- tab managers are way more "secure" than the millions of chrome extensions that require total control of all websites you browse to. The multi-threaded and faster experience is just a matter of redesign. If UI people followed Linus's adage of never breaking compability with APIs we'd all be happier
    - michaelmrose 4y ago
      The XUL addon system essentially allowed addons and official components alike to monkey patch any aspect implemented in XUL and indeed each other. The potential for interaction between them is therefore unlimited. When you say that its "just a matter of redesign" you are saying that if only infinite resources could be expended to avoid you never having to change anything at all the world could be a grand place. What you are failing to understand is that the browser is being secured first and foremost not against extension developers but against malicious actors. If the entire way the browser interacts is it self subject to monkey patching its infinitely harder and perhaps impossible to properly secure the single most exposed application vs the outside world. Ideally the functionality once implemented as monkey patching can be provided by a defined interface with the addon system and indeed this is exactly what one sees today with most broadly useful extensions ported. Incidentally if you want to analogize Firefox vs Linux the interface that is not supposed to break is the interaction with the web itself to the degree that this is possible. Linux actually makes external out of tree addons which touch let alone modify the kernel break/update themselves constantly. Linus would never have been stupid enough to commit to something like XUL for the kernel wherein he himself would be responsible for keeping thousands of monkey patching addons working while trying to evolve the kernel.
roenxi 4y ago
As we read this, let us reflect that this reasonable and mature position resulted in a ~2% market share [0]. Still respectable at 1 person in 50, I suppose, but not trending in a way people are going to feel proud about. Mozilla accepted Google's framing on what a web browser should be, and ended up in a world where it only makes sense to use chromium-based browsers since they better implement that vision. Firefox was always going to be a niche browser once Google got serious, but at least it could have been an interesting niche. Possibly it could be compared to Emacs - some people just love it because it was that customisable but it doesn't get a lot of love in the mainstream. Now it is just unimpressive. Which is remarkable given the wide range of impressive things it could do up to 2016 that it cannot do today. [0] https://gs.statcounter.com/browser-market-share/all/worldwide/2022 https://gs.statcounter.com/browser-market-share/all/worldwid...
- retcond 4y ago
  That interesting niche is at the Pale Moon browser initiative and their very interesting derivatives. Pale Moon still runs XUL.
  - cmeacham98 4y ago
    Correct, which completely disproves the idea that FF adoption is in any meaningful way driven by (the lack of) XUL support. If that was true, we'd expect to see forks like Pale Moon be _way_ more popular.
    - imiric 4y ago
      I disagree. The XUL forks serve their purpose well, but their lack of popularity is more due to being built by a very small team of volunteers, who've taken on the thankless and gargantuan task of maintaining the aging codebases of both Firefox and XUL addons, backporting security fixes from upstream, all the while fighting against limitations imposed by Mozilla as mainstream Firefox moved on. There's no reasonable chance that such a project could ever build a user base to register as even a blip on the market share graphs. Some people avoid it precisely because of this doomed factor. Personally, I can't rely on nor trust that a project of that scale is able to navigate the security minefield that modern browsers are, and fix all the routinely discovered issues, let alone those that remain hidden and unreported. So choosing to use it is a conscious acknowledgement that you're sacrificing security for those other features, and very few people are willing to make that sacrifice.
c-smile 4y ago
Sic transit gloria mundi... XUL, WPF, XAML ... Main characteristic of these markups is that they define not semantic but presentational DOM. Presentational DOM is what old HTML (v.1..3) was all about: all those <FONT>s, etc. So layout has not one source of truth (CSS) but also presentational elements (<hbox>, etc). Systems with multiple sources of truth do not play well as we know - person who has two watches does not know real time. Problem is that XUL was naively transformed into display:flex and now CSS declaration width:100px is not a source of truth either, display:flex in galaxy far, far away can change real box width in non-obvious manner.
- Spivak 4y ago
  How could flex work without the ability to deform anything not explicitly nailed down? You need to specify the relative sizes of things, some of those things might be rigid, and the division of how much each item is deformed is dynamic. You would need all new flexi-units like fpx, fem, f% or you could just say everything in flex is now flexi- unless you say it’s rigid and use the same units which is more sane to me.
  - c-smile 4y ago
    This div { width:100px; height:100px; margin:1fx; // all margins, horizontal and vertical } will place div in the middle/center of its container. a) is significantly easier to understand b) is more flexible than bunch of flexbox props and c) does not break CSS box model and d) has clear physical model, see : https://terrainformatica.com/2018/12/11/10-years-of-flexboxing/ https://terrainformatica.com/2018/12/11/10-years-of-flexboxi... Just try to define same thing using flexbox...
devwastaken 4y ago
The removal of XUL is when Mozilla's position as an innovator and industry leader showed it had died. Chrome is ubiquitous not because of chrome, but because chromium is the most friendly open platform to use. V8 regularly runs laps around spider monkey, and has been embedded into thousands of critical business infrastructure. V8 isolates being a big feature. Spider monkey hasn't kept up. It's Firefox only. Chromium can result in things like electron. Firefox could have positioned themselves that way, but chose isolation. They only want to develop Firefox, and because of that they are doing a poor job. The math doesn't work out, eventually Firefox will have to become a chromium skin, and it will be all the better for it. Google is, after all, the ones paying for Mozilla to exist outside of their yahoo deal.
- yoasif_ 4y ago
  >Spider monkey hasn't kept up. It's Firefox only. That isn't true though: https://en.wikipedia.org/wiki/SpiderMonkey#Use https://en.wikipedia.org/wiki/SpiderMonkey#Use
fidgewidge 4y ago
It's interesting to think about what alternatives to this path could have existed. The author makes what he thinks is a watertight argument about security, but it's a lot leakier than is made clear. Mozilla didn't actually have an extensions malware problem at any point. That's why he won't cite any actual examples, saying in the comments he's afraid of lawsuits because the extensions came from "high profile apps". High profile apps the user is choosing to install are by definition not malware, yet Mozilla allowed a bizarre authoritarian impulse to develop amongst its engineers that let them rationalize to themselves that any desktop app that extended Firefox (i.e. outside the add-ons site they controlled) was "malware" regardless of what it did or whether users actually liked it. That's a totally incorrect definition, which is why they are so squirrelly about it, any why users reject it. Nor is the API stability argument well founded. Nothing would have stopped them introducing stable APIs they could commit to and helping extension authors migrate. They could have implemented WebExtensions as well as continuing to allow XUL extensions, which would have given the extensions that didn't need more functions stability without killing the others. Why could Google design such APIs but not Mozilla? The real reason they didn't want to does seem to be described - designing APIs and then sticking to them is tedious and boring work. The chrome guys didn't have to do that, at least for a while. What fun! In a parallel universe, Mozilla realized that whilst performance and security are important, they're also largely a pure function of how much you depend on engineers and thus they could never win against Chrome in that department. The only battlefield on which they could gain advantage was the field of ideas. Features were the one place their smaller engineering budget wouldn't automatically lose against Google, but clearly by this time Mozilla had run out of ideas for features users might want. XUL extensions were a valuable proving ground for features they could then later have merged into the main browser, potentially finding even just one idea that Chrome would struggle to match. Reducing the maintenance burden could have been done in all sorts of ways, for example by using a Linux Kernel style model in which popular extensions are invited to be developed in tree where they can be activated during testing cycles and refactored atomically as the browser changes. Typescript would have made this easier, but xpcom already offered some type safety.
- imiric 4y ago
  I agree. I don't doubt that XUL had severe limitations, security issues, and was a nightmare to maintain. But all of those were mostly problems for Mozilla developers to deal with. Users didn't experience them, and any security and performance issues could've been addressed without scrapping the entire framework. But Mozilla chose to prioritize developer well-being over the needs of their users, and chase some performance and productivity metrics compared to a novel browser built by a company with enormous amount of resources to throw at it. And years later its old user base is still salty about that decision, watching how Mozilla becomes even more irrelevant, while being in denial and celebrating their current direction. It's a sad state of affairs, and a documentary should be made once Mozilla finally shuts down.
scotty79 4y ago
For me moving to Chrome was a simple case of, wow, it's fast and when it dies a single tab dies not the whole browser. I lingered a bit in Firefox professionally because of FireBug but once Chrome Dev Tools got decent I switched completely. Now Chrome stopped showing me more than n tabs when I open too many and doesn't show UI to scroll invisible ones into view. This happens on my every windows machine. Chrome feels janky nowadays for me. So I'm trying to get back to Firefox but it's a bit hard. Recently I couldn't even get Bitwarden to work in Firefox on Windows. Fortunately I managed to switch to DucDuckGo browser on Android.
- yoasif_ 4y ago
  >Recently I couldn't even get Bitwarden to work in Firefox on Windows. That is weird - works fine on my end. What happens?
  - scotty79 4y ago
    When I try to log into bitwarden I see that something (captcha?) was blocked in the small area undee the login and password inputs. Error message there doesn't point me out to any resource about how I could make it work.
    - yoasif_ 4y ago
      Odd, I don't think I have ever seen a captcha when logging in. Probably worth reporting a bug: https://github.com/bitwarden/clients/issues https://github.com/bitwarden/clients/issues
tinus_hn 4y ago
In a few years Chrome will be dominant and Google will be tempted to rest on its laurels, remove resources and let it stall. It wouldn’t surprise me if the only free reasonable alternative has another comeback in the cards. If it still exists by then, of course.

111 points by imiric 4y ago

deleted 4y ago

[deleted]

Such a post at that time would have greatly improved people's response to the change. Instead what we usually get is a PR sanitized gobbledygook which occupies space without speaking much at all. Now a similar thing is happening with Firefox Android and their extensions. Firefox can easily run most extensions but it's hidden behind a config in a canary release of the browser. No doubt there are some good reasons for it but we simply do not know. Ultimately this is a fault common among almost every product designer. They refuse to explain their decisions fearing (perhaps justly) that they may be proven wrong. Many such cases

wolpoli 4y ago
The product designers don't realize that a lot of the backlash comes from the technically-minded audience, and that their usual approach of highlighting user benefits only further fuels distrust among that vocal community.
commoner 4y ago
> Now a similar thing is happening with Firefox Android and their extensions. Firefox can easily run most extensions but it's hidden behind a config in a canary release of the browser. No doubt there are some good reasons for it but we simply do not know. Ultimately this is a fault common among almost every product designer. They refuse to explain their decisions fearing (perhaps justly) that they may be proven wrong. There were no good reasons for Mozilla to restrict extensions on Firefox for Android. It was a stupid decision that alienated Firefox's user base on Android with no real benefits. However, Mozilla has finally listened to the negative feedback and custom add-on collections are now available on Firefox Beta for Android: https://www.ghacks.net/2022/10/20/firefox-beta-for-android-now-supports-custom-add-on-collections/ https://www.ghacks.net/2022/10/20/firefox-beta-for-android-n... Mozilla also said they would start working on WebExtensions on Firefox for Android this year. The goal is to have feature parity with desktop Firefox, which includes retaining the Manifest v2 features that uBlock Origin uses: https://blog.mozilla.org/addons/2022/12/15/new-extensions-available-now-on-firefox-for-android-nightly/ https://blog.mozilla.org/addons/2022/12/15/new-extensions-av... While Mozilla has made numerous missteps in the past, it looks like they're finally moving in the right direction.
- m-p-3 4y ago
  What also annoys me is they disabled about:config on the Firefox for Android Stable release..
- yjftsjthsd-h 4y ago
  However, Mozilla has finally listened to the negative feedback and custom add-on collections are now available on Firefox Beta for Android Anything to avoid putting a useful feature in a stable release or making it convenient, I suppose...
- its-summertime 4y ago
  The API being unfinished, meaning web extensions could fail in random, unexpected ways, sounds like a good reason to me?
  - cuteboy19 4y ago
    No reason why it can't be hidden behind a WARNING:MAY BREAK or about:config. But they implemented it in such a roundabout manner. Anyways the issue is not the decision but rather the communication about it. Ideally a dev post about this could have satisfied a lot of people but they chose to go with the PR soup method. It's not even that these are exclusive, include a link to dev post in the soup
    - its-summertime 4y ago
      https://blog.mozilla.org/addons/2020/09/02/update-on-extension-support-in-the-new-firefox-for-android/ https://blog.mozilla.org/addons/2020/09/02/update-on-extensi... and https://blog.mozilla.org/addons/category/mobile/ https://blog.mozilla.org/addons/category/mobile/ ? > We looked at add-on usage on Android, and made the decision to start by building support for add-ons in the Recommended Extensions program that were commonly installed by our mobile users. Enabling a small number of extensions in the initial rollout also enabled us to ensure a good first experience with add-ons in the new browser that are both mobile-friendly and security-reviewed. And progress is on the MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

imbnwa 4y ago

I remember using Songbird in the late 00s, a music player built on top of XULRunner, as well as a twitter client. They're not exactly 1-to-1, but there's something funny to how Electron provides that browser-based platform for desktop apps now.

Semaphor 4y ago
It's even mentioned in the article. I think I tried it back then, but preferred foobar2k.
- deleted 4y ago
  [deleted]
notRobot 4y ago
I remember getting a fork of it, Philips Songbird, with an MP3 player and using it for a few years on a Windows XP machine. Worked much better than iTunes, and I actually kinda miss it a lot.
- TedDoesntTalk 4y ago
  I worked hard to keep my addon compatible with Songbird.
giantrobot 4y ago
I was partial to Flock, another XUL browser. It integrated a bunch of of social media APIs of the day in interesting ways.
- thakoppno 4y ago
  I remember Flock fondly. Any recall why it didn’t work out? Did Firefox’s ascendency stall out Flock?
  - giantrobot 4y ago

spankalee 4y ago

> Firefox developers started porting components from XUL to HTML5 More specifically, Firefox's UI wasn't just ported to HTML5, but to web components. This means much of two of the three major browsers (also parts of Chrome and Chrome OS) are using web components for the UI. Part of what enabled a move from XUL was that HTML finally got custom elements, where XUL/XBL had had custom components for a long time.

chrismorgan 4y ago
I don’t believe that Web Components had anything to do with it at all. When you control the scripting environment, and would be instantiating in scripting rather than in serialised markup, Custom Elements are one of the more superfluous features of the web platform: everything you can do with them, you can do every bit as effectively without them, at no meaningful cost or cost saving. The point where things get a little more interesting is when you introduce Shadow DOM, because then you do have genuine capabilities that can’t be expressed in other ways (though whether you want to may be another matter). But the real kicker, in my assessment and conclusion, is that both of these features landed after the migration from XUL to HTML began. (Not all that long after, and they have since been used variously, but the moving initiatives began before they were available.)
- bgrins 4y ago
  I worked on this project - Web Components had a lot to do with it. It's true they weren't feature complete in Firefox when we started the project (notably missing Shadow DOM) - but the first migration from late 2017 was XBL->Custom Element (https://bugzilla.mozilla.org/show_bug.cgi?id=1500626 https://bugzilla.mozilla.org/show_bug.cgi?id=1500626), and we used the migration project to inform performance and feature work for Web Components within Firefox. We could have converted the bindings to JS modules (and we did plenty of that too), but Web Components were key because they allowed us to migrate in-place with near API compatibility rather than rewriting the UI. I have a post at https://briangrinstead.com/blog/firefox-webcomponents/ https://briangrinstead.com/blog/firefox-webcomponents/ with more detail on that point.

MollyRealized 4y ago

I have to say, I miss Keyconfig SO badly.

metadat 4y ago
I'd never heard of KeyConfig. To save others the effort: It was a keyboard customizer XUL extension for Firefox and Thunderbird. http://kb.mozillazine.org/Keyconfig_extension http://kb.mozillazine.org/Keyconfig_extension
ashtonabc 4y ago
Keyconfig and other legacy extensions are still available for modern Firefox with a modified userChromeJS: https://github.com/xiaoxiaoflood/firefox-scripts/tree/master/extensions/keyconfig https://github.com/xiaoxiaoflood/firefox-scripts/tree/master...
cycomanic 4y ago
For thunderbird there is tbkeys which is the spiritual successor. I use it to implement mutt like keybindings.

dang 4y ago

Discussed at the time (of the article): Why Did Mozilla Remove XUL Add-Ons? - https://news.ycombinator.com/item?id=24231017 https://news.ycombinator.com/item?id=24231017 - Aug 2020 (336 comments)

sabellito 4y ago

I might be one of the dozens of people in the world who actually shipped production software using XUL. It's a generic admin software for recruiting companies, still has some 200 daily users. At the time, in 2004, PrototypeJS was all the rage, and XmlHTTPRequest didn't exist yet. XUL helped us ship a more rich user experience without extreme pain. The whole thing was even a pseudo-SPA, using iframes everywhere, which we also used to fetch extra data for some pages without navigating.

fzzzy 4y ago
XmlHTTPRequest existed, it's just that Firefox hadn't implemented it yet. IE had it since 1999.
- sabellito 4y ago
  You are, of course, correct!
- unscaled 4y ago
  XMLHttpRequest was available since Firefox was called Firefox[1], and it should have been at least partly functional in 2002 when Phoenix 0.1 (the predecessor to Firebird and Firefox) was released. In 2004, Firebird just got renamed to Firefox (on version 0.8) and Safari implemented XHR. Opera and Konqueror would implement it in 2005. The main issue obstructing the use of XHR was not browser compatibility. Internet Explorer still had 95% market share, and almost nobody cared about compatibility with other browsers then. The issue was mostly about awareness, and lack of proper tooling. The term AJAX was only coined in 2005, so the technique of using XHR to reduce page refreshes and improve page responsiveness didn't even have a name. It was used here in there by savvy web developers, but it wasn't systematic. Before 2005, very few websites were built entirely on XHR. It was out there, lurking in the shadows, but not transforming the way web was done yet. Outlook Web Access (for which XHR was developed) is an obvious mention, but the first site that got XR popular was probably Gmail Beta, in 2004. I think a lot of developers suddenly wanted to replicate it, and with the popularization of AJAX in 2005, learning resources become easier to find, libraries and frameworks got developed to make its usage easier (anybody said jQuery?) and so on. [1] See: https://bugzilla.mozilla.org/show_bug.cgi?id=237606 https://bugzilla.mozilla.org/show_bug.cgi?id=237606. Interestingly enough, this bug report was about trying to access an XPCOM component from a web page, not about an incompatibility with whatever IE was doing. IE didn't even have XPCOM after all!

superkuh 4y ago

You can still use XUL based add-ons. You just can't do it in the chrome-in-spirit modern Firefox. There are plenty of great Firefox forks still maintained to this day that support XUL add-ons. And despite Mozilla's attempts to stop it users have scraped and collected together all the old addons in various archives. I'm not saying this is a good solution for facebook/youtube/twitch/etc users that treat their browser as an OS to run applications. It's not. But if you surf with javascript disabled and tend to only use actual websites written in HTML it's still viable. (the html web still exists, it's just not as loud and attention grabbing as the megacorp javascript silos)

smabie 4y ago
who actually surfs with js enabled? gotta be less than 1%
- throwaway290 4y ago
  You wouldn't know because none of the trackers would fire...
  - dathinab 4y ago
    That is a common misconception. There are multiple ways to track people with similar precision as common JS trackers without using JS. When it comes to simple statistics there are even far more ways. I would go a step further and say that JS tracking is mostly limited to a certain very small subset of people which making it likely less then 0.01%, potentially even much less then that. Most of the web is inaccessible without JS including many of the most widely used websites and most users don't even understand why not using JS could do anything good. Or understand what JS is. Expecting any not completely irrelevant non-JS browser share is just not realistic.
    - throwaway290 4y ago
      This is all beyond the point which was that stats about no-JS users are almost nonexistent. You can keep saying "but there can't be many people using web without js" but they literally fly under your radar. > There are multiple ways to track people with similar precision as common JS trackers without using JS. And almost no one uses them. > I would go a step further and say that JS tracking is mostly limited to a certain very small subset of people which making it likely less then 0.01%, potentially even much less then that. I barely see a project that does anything except Google Analytics at default settings with a script tag. > Most of the web is inaccessible without JS including many of the most widely used websites "Most of the web" actually works. Some of the popular ones don't but Wikipedia/Google/Amazon/Facebook (to a degree) are OK. All latest front-end frameworks are built to deliver working HTML with minimal JS instead of SPAs. > most users don't even understand why not using JS could do anything good. Or understand what JS is. There was a time most users didn't even understand why not using IE could do anything good or understand what a browser is. Times change.

jerrysievert 4y ago

I was very sad when XUL disappeared from Firefox - I had written a serial plugin in c++ via XPCOM, which had allowed us to more easily test and deal with firmware updates in the hardware we ran, and having XUL in Firefox meant for fairly quick and lightweight touchscreen applications that could be shipped to customers with very low hardware requirements, nothing like you'd need for electron today. these were for point-of-decision kiosks, and were so easy to build and maintain, truly a great era.

2h 4y ago

Firefox Android has been awful for a while now. You cant sideload extesions on Android for at least two years now, with the only workaround being use an older Firefox: https://github.com/mozilla-mobile/fenix/issues/20736 https://github.com/mozilla-mobile/fenix/issues/20736 then they close the issue and move to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1796184 https://bugzilla.mozilla.org/show_bug.cgi?id=1796184

tredre3 4y ago
This has nothing to do with the XUL addons discussed in the article.
binarysneaker 4y ago
But you can run Firefox Nightly and use a custom extensions list. This is how I have all my regular extensions running great on Android.
- 2h 4y ago
  that requires registration on AMO. I should not have to do that to install an extension that I WROTE

figital 4y ago

Being able to script buttons in my browser's toolbars is a feature I miss (circa the Jetpack era of Firefox). It greatly increased my productivity. Doing some of this now on my Linux desktop using jgmenu ... it's not a browser though ... it's a floating data-driven start menu. Very fun.

schneems 4y ago

It’s been over a decade since I touched a Firefox addon and I still remember their ghostbusters easter-egg/joke. Went something like: keymaster/gatekeeper/thereisonly.xul

chrismorgan 4y ago
http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xu...
bitwize 4y ago
Also explains why their in-browser debugger was called Venkman.

qwertox 4y ago

XUL was great. There was this tabs extension which allowed to have multiple rows of tabs open and even more rows accessible through scrolling with the mouse wheel. Or another one which allowed to tile pages in one browser window.

51Cards 4y ago
I still miss TabMixPlus in my daily browsing. Haven't found a tab manager since that can match what it did for me.
- yoasif_ 4y ago
  You could try TabMixPlus: https://github.com/onemen/TabMixPlus https://github.com/onemen/TabMixPlus

pmoriarty 4y ago

I miss Pentadactyl

ZekeSulastin 4y ago
Have you given Tridactyl a shot?
- mariusor 4y ago
  Tridactyl is nowhere near as usable as Pentadactyl was, and its injection of JS/CSS in every page you visit is very, very intrusive. Sadly it's the only option that is usable for me at the moment, but I think everyone - including its devs - would agree that it can never reach the same level to Pentadactyl due to not having access to the browser's chrome.
  - bovine3dom 4y ago
    About five years ago we had agreement in principle with Mozilla to extend the web extension API to accept keypresses from anywhere, provided that someone did the work to write that API. We started it [1] but lost interest because we think Tridactyl works mostly fine without it (press ctrl+, anywhere to get back to Tridactyl) and I have always found more urgent things to improve. I'd be happy to help anyone who wanted to pick it up, but a lot of the political work of persuading Mozilla that such an API would be useful would need to be restarted since most of the people we persuaded in the past have now left Mozilla. [1]: https://github.com/tridactyl/keyboard-api/ https://github.com/tridactyl/keyboard-api/
michaelmrose 4y ago
https://github.com/tridactyl/tridactyl https://github.com/tridactyl/tridactyl

cultureulterior 4y ago

There was no excuse, they should just bring xul back

michaelmrose 4y ago
https://yoric.github.io/post/why-did-mozilla-remove-xul-addons/ https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... People wanted a faster, more secure, multi-threaded experience. > Note: Having read in comments that some users apparently do not care about security, let me add that being secure is a really, really important point for Mozilla and has been since the first day. Regardless of add-ons, not having security means that an exploit is eventually going to show up that will steal user’s passwords and use them to steal their bank accounts – and that exploit will get sold around and will soon show up everywhere. Firefox developers fight this threat daily by all sorts of means, including code reviews, defensive programming, crash scene investigations, several types of sandboxing, static analysis, memory-safe languages, … Consequently, for Mozilla, if a feature prevents us from achieving great security, we always pick security over features. You should read the link.
- cultureulterior 4y ago
  I did. The security argument is a poor one- tab managers are way more "secure" than the millions of chrome extensions that require total control of all websites you browse to. The multi-threaded and faster experience is just a matter of redesign. If UI people followed Linus's adage of never breaking compability with APIs we'd all be happier
  - michaelmrose 4y ago
    The XUL addon system essentially allowed addons and official components alike to monkey patch any aspect implemented in XUL and indeed each other. The potential for interaction between them is therefore unlimited. When you say that its "just a matter of redesign" you are saying that if only infinite resources could be expended to avoid you never having to change anything at all the world could be a grand place. What you are failing to understand is that the browser is being secured first and foremost not against extension developers but against malicious actors. If the entire way the browser interacts is it self subject to monkey patching its infinitely harder and perhaps impossible to properly secure the single most exposed application vs the outside world. Ideally the functionality once implemented as monkey patching can be provided by a defined interface with the addon system and indeed this is exactly what one sees today with most broadly useful extensions ported. Incidentally if you want to analogize Firefox vs Linux the interface that is not supposed to break is the interaction with the web itself to the degree that this is possible. Linux actually makes external out of tree addons which touch let alone modify the kernel break/update themselves constantly. Linus would never have been stupid enough to commit to something like XUL for the kernel wherein he himself would be responsible for keeping thousands of monkey patching addons working while trying to evolve the kernel.

roenxi 4y ago

As we read this, let us reflect that this reasonable and mature position resulted in a ~2% market share [0]. Still respectable at 1 person in 50, I suppose, but not trending in a way people are going to feel proud about. Mozilla accepted Google's framing on what a web browser should be, and ended up in a world where it only makes sense to use chromium-based browsers since they better implement that vision. Firefox was always going to be a niche browser once Google got serious, but at least it could have been an interesting niche. Possibly it could be compared to Emacs - some people just love it because it was that customisable but it doesn't get a lot of love in the mainstream. Now it is just unimpressive. Which is remarkable given the wide range of impressive things it could do up to 2016 that it cannot do today. [0] https://gs.statcounter.com/browser-market-share/all/worldwide/2022 https://gs.statcounter.com/browser-market-share/all/worldwid...

retcond 4y ago
That interesting niche is at the Pale Moon browser initiative and their very interesting derivatives. Pale Moon still runs XUL.
- cmeacham98 4y ago
  Correct, which completely disproves the idea that FF adoption is in any meaningful way driven by (the lack of) XUL support. If that was true, we'd expect to see forks like Pale Moon be _way_ more popular.
  - imiric 4y ago
    I disagree. The XUL forks serve their purpose well, but their lack of popularity is more due to being built by a very small team of volunteers, who've taken on the thankless and gargantuan task of maintaining the aging codebases of both Firefox and XUL addons, backporting security fixes from upstream, all the while fighting against limitations imposed by Mozilla as mainstream Firefox moved on. There's no reasonable chance that such a project could ever build a user base to register as even a blip on the market share graphs. Some people avoid it precisely because of this doomed factor. Personally, I can't rely on nor trust that a project of that scale is able to navigate the security minefield that modern browsers are, and fix all the routinely discovered issues, let alone those that remain hidden and unreported. So choosing to use it is a conscious acknowledgement that you're sacrificing security for those other features, and very few people are willing to make that sacrifice.

c-smile 4y ago

Sic transit gloria mundi... XUL, WPF, XAML ... Main characteristic of these markups is that they define not semantic but presentational DOM. Presentational DOM is what old HTML (v.1..3) was all about: all those <FONT>s, etc. So layout has not one source of truth (CSS) but also presentational elements (<hbox>, etc). Systems with multiple sources of truth do not play well as we know - person who has two watches does not know real time. Problem is that XUL was naively transformed into display:flex and now CSS declaration width:100px is not a source of truth either, display:flex in galaxy far, far away can change real box width in non-obvious manner.

Spivak 4y ago
How could flex work without the ability to deform anything not explicitly nailed down? You need to specify the relative sizes of things, some of those things might be rigid, and the division of how much each item is deformed is dynamic. You would need all new flexi-units like fpx, fem, f% or you could just say everything in flex is now flexi- unless you say it’s rigid and use the same units which is more sane to me.
- c-smile 4y ago
  This div { width:100px; height:100px; margin:1fx; // all margins, horizontal and vertical } will place div in the middle/center of its container. a) is significantly easier to understand b) is more flexible than bunch of flexbox props and c) does not break CSS box model and d) has clear physical model, see : https://terrainformatica.com/2018/12/11/10-years-of-flexboxing/ https://terrainformatica.com/2018/12/11/10-years-of-flexboxi... Just try to define same thing using flexbox...

devwastaken 4y ago

The removal of XUL is when Mozilla's position as an innovator and industry leader showed it had died. Chrome is ubiquitous not because of chrome, but because chromium is the most friendly open platform to use. V8 regularly runs laps around spider monkey, and has been embedded into thousands of critical business infrastructure. V8 isolates being a big feature. Spider monkey hasn't kept up. It's Firefox only. Chromium can result in things like electron. Firefox could have positioned themselves that way, but chose isolation. They only want to develop Firefox, and because of that they are doing a poor job. The math doesn't work out, eventually Firefox will have to become a chromium skin, and it will be all the better for it. Google is, after all, the ones paying for Mozilla to exist outside of their yahoo deal.

yoasif_ 4y ago
>Spider monkey hasn't kept up. It's Firefox only. That isn't true though: https://en.wikipedia.org/wiki/SpiderMonkey#Use https://en.wikipedia.org/wiki/SpiderMonkey#Use

fidgewidge 4y ago

It's interesting to think about what alternatives to this path could have existed. The author makes what he thinks is a watertight argument about security, but it's a lot leakier than is made clear. Mozilla didn't actually have an extensions malware problem at any point. That's why he won't cite any actual examples, saying in the comments he's afraid of lawsuits because the extensions came from "high profile apps". High profile apps the user is choosing to install are by definition not malware, yet Mozilla allowed a bizarre authoritarian impulse to develop amongst its engineers that let them rationalize to themselves that any desktop app that extended Firefox (i.e. outside the add-ons site they controlled) was "malware" regardless of what it did or whether users actually liked it. That's a totally incorrect definition, which is why they are so squirrelly about it, any why users reject it. Nor is the API stability argument well founded. Nothing would have stopped them introducing stable APIs they could commit to and helping extension authors migrate. They could have implemented WebExtensions as well as continuing to allow XUL extensions, which would have given the extensions that didn't need more functions stability without killing the others. Why could Google design such APIs but not Mozilla? The real reason they didn't want to does seem to be described - designing APIs and then sticking to them is tedious and boring work. The chrome guys didn't have to do that, at least for a while. What fun! In a parallel universe, Mozilla realized that whilst performance and security are important, they're also largely a pure function of how much you depend on engineers and thus they could never win against Chrome in that department. The only battlefield on which they could gain advantage was the field of ideas. Features were the one place their smaller engineering budget wouldn't automatically lose against Google, but clearly by this time Mozilla had run out of ideas for features users might want. XUL extensions were a valuable proving ground for features they could then later have merged into the main browser, potentially finding even just one idea that Chrome would struggle to match. Reducing the maintenance burden could have been done in all sorts of ways, for example by using a Linux Kernel style model in which popular extensions are invited to be developed in tree where they can be activated during testing cycles and refactored atomically as the browser changes. Typescript would have made this easier, but xpcom already offered some type safety.

imiric 4y ago
I agree. I don't doubt that XUL had severe limitations, security issues, and was a nightmare to maintain. But all of those were mostly problems for Mozilla developers to deal with. Users didn't experience them, and any security and performance issues could've been addressed without scrapping the entire framework. But Mozilla chose to prioritize developer well-being over the needs of their users, and chase some performance and productivity metrics compared to a novel browser built by a company with enormous amount of resources to throw at it. And years later its old user base is still salty about that decision, watching how Mozilla becomes even more irrelevant, while being in denial and celebrating their current direction. It's a sad state of affairs, and a documentary should be made once Mozilla finally shuts down.

scotty79 4y ago

For me moving to Chrome was a simple case of, wow, it's fast and when it dies a single tab dies not the whole browser. I lingered a bit in Firefox professionally because of FireBug but once Chrome Dev Tools got decent I switched completely. Now Chrome stopped showing me more than n tabs when I open too many and doesn't show UI to scroll invisible ones into view. This happens on my every windows machine. Chrome feels janky nowadays for me. So I'm trying to get back to Firefox but it's a bit hard. Recently I couldn't even get Bitwarden to work in Firefox on Windows. Fortunately I managed to switch to DucDuckGo browser on Android.

yoasif_ 4y ago
>Recently I couldn't even get Bitwarden to work in Firefox on Windows. That is weird - works fine on my end. What happens?
- scotty79 4y ago
  When I try to log into bitwarden I see that something (captcha?) was blocked in the small area undee the login and password inputs. Error message there doesn't point me out to any resource about how I could make it work.
  - yoasif_ 4y ago
    Odd, I don't think I have ever seen a captcha when logging in. Probably worth reporting a bug: https://github.com/bitwarden/clients/issues https://github.com/bitwarden/clients/issues

tinus_hn 4y ago

In a few years Chrome will be dominant and Google will be tempted to rest on its laurels, remove resources and let it stall. It wouldn’t surprise me if the only free reasonable alternative has another comeback in the cards. If it still exists by then, of course.