7 ms·

> 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 a

• jolmg 6y ago
  >> * 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.
  • gibolt 6y ago
    Codebases and products aren't that simple. 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).
  • marcinzm 6y ago
    >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.
    • Polylactic_acid 6y ago
      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.
      • GoblinSlayer 6y ago
        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.
  • duskwuff 6y ago
    > 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.
• perryizgr8 6y ago
  > 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.
  • bayindirh 6y ago
    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.
    • nix23 6y ago
      > Now The speed of Firefox at home is equal with the speed of Chrome at Work, Firefox at work is slightly behind. Ehhh ;)
    • jeroenhd 6y ago
      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.
• ekianjo 6y ago
  > * 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.
  • KMag 6y ago
    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.)
    • cultureulterior 6y ago
      But they don't extend the sandbox (Look at tab tree). Also, it's impossible to demonstrate demand for an extension that doesn't exist.
      • takluyver 6y ago
        I'm not sure what you mean about tab tree. There are tab tree WebExtensions.
        • eitland 6y ago
          yep, but you either have to let it coexist with the main tab bar or go further and further to manually disable that.
        • chaorace 6y ago
          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.