6 ms·

A car analogy is perfect here. Google Chrome is kind of like a sedan, something convenient for most people. Firefox is kind of like a pickup truck, less conve

A car analogy is perfect here. Google Chrome is kind of like a sedan, something convenient for most people. Firefox is kind of like a pickup truck, less convenient for a lot of people but more powerful and useful for the people who need them. This move is kind of like a pickup truck manufacturer realizing that sedans are more common than pickup trucks, then thinking sedans don't have beds in the back, and removing the bed from their pickup truck. Then afterwards, they're confused why people don't like this change.

msbarnett 10y ago
A more accurate metaphor would involve the sedan have modern safety features the lack of which make the truck increasingly risky to drive but which the truck is unable to adopt without shedding technical limitations imposed by the bed.
- MiddleEndian 10y ago
  Except in this case it's like removing the bed so I can't hypothetically transport large quantities of nitroglycerin (addons with tracking) but they're preventing me from transporting anything of interest (tab mix plus). I'll just use the Firefox LTS until it stops working with the modern web. By then hopefully the issue will be solved (perhaps by me, as I'm a dev).
  - msbarnett 10y ago
    > Except in this case it's like removing the bed so I can't hypothetically transport large quantities of nitroglycerin (addons with tracking) No? That's not what's motivating this at all. The problem is the XUL/XPCOM API are fundamentally incomposable with completely sandboxed per-tab processes a la Chromium and other isolating security changes, because of assumptions they impose on Firefox internals. If you turn on multiple processes in Firefox there's a bunch of complicated shims that half-keep some extensions working some of the time, but it's an uphill battle to support an API that never conceived of the idea. It needs to be shitcanned to move forward.
    - barrkel 10y ago
      Sufficient extension points with APIs to reimplement the interesting addons should have been made available and working years before dropping compatibility. From the conversations happening around the most popular addons, that has not been the case. It may be that the old APIs need to die; but this way isn't the way to kill the old API. You need as near to complete overlapping for a long time to get people to port over. You don't do cliff edges. That's how you kill your userbase.
      - GraemeLion 10y ago
        But this is not a secret. This has been discussed repeatedly for at least 5 years now. The current XUL methodology CANNOT sustain, and everyone knew this. But everyone also knew Mozilla was famous for putting off being confrontational, so nobody actually thought this was going to happen, so nobody really communicated with mozilla on what would be needed to avoid this happening. Now Mozilla has finally set a date (which maybe they won't push back YET AGAIN), and people who've not been doing work on their extensions in preparation for this, or who did not talk to Mozilla about what they need when Mozilla repeatedly asked for that information, are suddenly afraid that they're going to be left in the cold. Mozilla does almost absolutely everything on public lists. This is all completely readable. The common thought was "they're not really ever going to do this, so we don't really need to present them with what we need, because we know they won't do this." So what else can Mozilla do? Nobody actually believed they were going to really set a cut off date. Everyone thought it'd just be pushed back over and over like it always has been.
        kuschku 10y ago
        > The current XUL methodology CANNOT sustain, and everyone knew this. Yet we still don't have a replacement for even a tenth of what it could do today! Once Firefox 57 is released, I'll lose the ability to use Firefox at all, and won't be able to regain it for several years. Just because no one though to consider what APIs one might have to provide before deprecating the old ones.
- CaptSpify 10y ago
  > unable to adopt I'd argue that they are able to adopt a better security model, they are choosing not to.
SilasX 10y ago
Yes, Firefox is supposed be more like a hobbyist's car, optimized for tinkering and non-mainstream features. Except that one day they're suddenly disallowing core features that such hobbyists care about. Suddenly, they don't allow manual transmissions "for security reasons" (you try to plug one in and the internal computer shuts down and refuses to boot, even though you set the computer to expect a manual). And they've worked with transportation agencies to ensure that their cars get pulled over when they're using a manual. I was so upset that I wrote a hitler parody when FF stopped supporting unsigned addons even when the user finds the settings and authorizes it. https://youtube.com/watch?v=taGARf8K5J8 https://youtube.com/watch?v=taGARf8K5J8 "Why not just shrink wrap the browser and make me buy it from Microsoft at Walmart!"

msbarnett 10y ago

A more accurate metaphor would involve the sedan have modern safety features the lack of which make the truck increasingly risky to drive but which the truck is unable to adopt without shedding technical limitations imposed by the bed.

MiddleEndian 10y ago
Except in this case it's like removing the bed so I can't hypothetically transport large quantities of nitroglycerin (addons with tracking) but they're preventing me from transporting anything of interest (tab mix plus). I'll just use the Firefox LTS until it stops working with the modern web. By then hopefully the issue will be solved (perhaps by me, as I'm a dev).
- msbarnett 10y ago
  > Except in this case it's like removing the bed so I can't hypothetically transport large quantities of nitroglycerin (addons with tracking) No? That's not what's motivating this at all. The problem is the XUL/XPCOM API are fundamentally incomposable with completely sandboxed per-tab processes a la Chromium and other isolating security changes, because of assumptions they impose on Firefox internals. If you turn on multiple processes in Firefox there's a bunch of complicated shims that half-keep some extensions working some of the time, but it's an uphill battle to support an API that never conceived of the idea. It needs to be shitcanned to move forward.
  - barrkel 10y ago
    Sufficient extension points with APIs to reimplement the interesting addons should have been made available and working years before dropping compatibility. From the conversations happening around the most popular addons, that has not been the case. It may be that the old APIs need to die; but this way isn't the way to kill the old API. You need as near to complete overlapping for a long time to get people to port over. You don't do cliff edges. That's how you kill your userbase.
    - GraemeLion 10y ago
      But this is not a secret. This has been discussed repeatedly for at least 5 years now. The current XUL methodology CANNOT sustain, and everyone knew this. But everyone also knew Mozilla was famous for putting off being confrontational, so nobody actually thought this was going to happen, so nobody really communicated with mozilla on what would be needed to avoid this happening. Now Mozilla has finally set a date (which maybe they won't push back YET AGAIN), and people who've not been doing work on their extensions in preparation for this, or who did not talk to Mozilla about what they need when Mozilla repeatedly asked for that information, are suddenly afraid that they're going to be left in the cold. Mozilla does almost absolutely everything on public lists. This is all completely readable. The common thought was "they're not really ever going to do this, so we don't really need to present them with what we need, because we know they won't do this." So what else can Mozilla do? Nobody actually believed they were going to really set a cut off date. Everyone thought it'd just be pushed back over and over like it always has been.
      - kuschku 10y ago
        > The current XUL methodology CANNOT sustain, and everyone knew this. Yet we still don't have a replacement for even a tenth of what it could do today! Once Firefox 57 is released, I'll lose the ability to use Firefox at all, and won't be able to regain it for several years. Just because no one though to consider what APIs one might have to provide before deprecating the old ones.
CaptSpify 10y ago
> unable to adopt I'd argue that they are able to adopt a better security model, they are choosing not to.

SilasX 10y ago

Yes, Firefox is supposed be more like a hobbyist's car, optimized for tinkering and non-mainstream features. Except that one day they're suddenly disallowing core features that such hobbyists care about. Suddenly, they don't allow manual transmissions "for security reasons" (you try to plug one in and the internal computer shuts down and refuses to boot, even though you set the computer to expect a manual). And they've worked with transportation agencies to ensure that their cars get pulled over when they're using a manual. I was so upset that I wrote a hitler parody when FF stopped supporting unsigned addons even when the user finds the settings and authorizes it. https://youtube.com/watch?v=taGARf8K5J8 https://youtube.com/watch?v=taGARf8K5J8 "Why not just shrink wrap the browser and make me buy it from Microsoft at Walmart!"