5 ms·

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

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.
        GraemeLion 10y ago
        Partially because when Mozilla initially said "XUL is going away, what do you guys need?" Everyone just laughed at them and said "No, it's not, you'll never replace it because it is too important in extensions", and then all went away. Where are the specs for what replaces it supposed to come from? And when they asked for those specs and got little answers, what were they supposed to do? Run around screaming "No we're serious this time, we really are going to drop this, and we really need you guys to work on getting requirements voiced? And also it'd be great if you took us seriously about e10s too!" One of my favorite extensions is vimperator. There are comments going back over a YEAR that there would be problems with e10s and XUL, and they were always just pushed off and ignored because it wasn't a current situation. I've got two or three other extensions whose github issues section mirrors the same situation. Some of them thought Mozilla would put in a "allow me to run dangerous addons" button and leave the code in play, but if add on developers can do that, then malicious add on developers can too.
CaptSpify 10y ago
> unable to adopt I'd argue that they are able to adopt a better security model, they are choosing not to.

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.
      - GraemeLion 10y ago
        Partially because when Mozilla initially said "XUL is going away, what do you guys need?" Everyone just laughed at them and said "No, it's not, you'll never replace it because it is too important in extensions", and then all went away. Where are the specs for what replaces it supposed to come from? And when they asked for those specs and got little answers, what were they supposed to do? Run around screaming "No we're serious this time, we really are going to drop this, and we really need you guys to work on getting requirements voiced? And also it'd be great if you took us seriously about e10s too!" One of my favorite extensions is vimperator. There are comments going back over a YEAR that there would be problems with e10s and XUL, and they were always just pushed off and ignored because it wasn't a current situation. I've got two or three other extensions whose github issues section mirrors the same situation. Some of them thought Mozilla would put in a "allow me to run dangerous addons" button and leave the code in play, but if add on developers can do that, then malicious add on developers can too.

CaptSpify 10y ago

> unable to adopt I'd argue that they are able to adopt a better security model, they are choosing not to.