7 ms·

The decision to revamp their extensions API also cost a lot of goodwill from the community. FF today may be faster and more secure than two years ago, but from

The decision to revamp their extensions API also cost a lot of goodwill from the community. FF today may be faster and more secure than two years ago, but from my perspective it has permanently lost some of its utility and appeal.

AsyncAwait 8y ago
It could never deploy multi-process with XUL cruft. Then the argument would be that Firefox is too far behind. You can never win everybody.
- kevin_thibedeau 8y ago
  Taking away XUL is not the problem. Leaving users with a crippled replacement is.
- gnomewascool 8y ago
  "e10s compatible" add-ons were as fully-featured as the "original" XUL add-ons and did not interfere with multi-process at all. For instance, VimFx was e10s compatible and could even run with Firefox Nightly (which allowed "legacy" add-ons), without disabling multi-process, until about Firefox 65(!), without major changes.
bad_user 8y ago
As a long time Firefox user I think the change in its extensions APIs is one of the greatest moves they did and I’m glad they did it. Chrome’s extensions were isolated, easy to develop and had a permissions system in place. To this day Firefox is still lagging behind in its isolation. For example Chrome can disable extensions in Incognito, but Firefox does not. Also if you’re not paying attention, Chrome won and it’s nearly a monopoly. This means browser extensions get developed for Chrome first. Having similar APIs helps with migration. I view the change as a good thing because I can finally develop my own extensions without headaches.
- JohnFen 8y ago
  > As a long time Firefox user I think the change in its extensions APIs is one of the greatest moves they did and I’m glad they did it. Not me. If the new extension system didn't present a loss of important (to me) functionality, then I'd think it was a good thing. But the loss of functionality happened, and that change is what makes the new Firefox unsuitable for me, so I stopped using it (and I never used Chrome).
- fiddlerwoaroof 8y ago
  Isolation isn’t a benefit for extensions: the whole point of extensions, bookmarklets, etc. is to be able to modify arbitrary aspects of the browsing experience in arbitrary ways.
  - Wowfunhappy 8y ago
    It's a balance, right? If browser extensions had kernel access, I think we'd all agree that's bad. Now, that's obviously an extreme, but where is the line? Up until recently†, I'm not aware of a situation where a popular Firefox extension was unable to work in Chrome due to Google restrictions. †I'm purposefully excluding the whole adblock thing, as that's super recent and thus not relevant here.
    - MrStonedOne 8y ago
      But it's not about the popular extensions. Now there is no more middle click to submit on forms and I used that at my old job to speed up a bunch of tedious tasks.
      - ZeikJT 8y ago
        That sounds trivial to implement in an extension at least. If there isn't one already I could probably take a crack at it.
    - TeMPOraL 8y ago
      > It's a balance, right? If browser extensions had kernel access, I think we'd all agree that's bad. Now, that's obviously an extreme, but where is the line? It is, and it boils down to the usual security vs. utility tradeoff - beyond some point, more secure means less useful. Kernel access is a stretch, but then again, I could make my computing experience much more pleasant if I had a deeper ability to control and inspect the browser from external software running on my computer.

AsyncAwait 8y ago

It could never deploy multi-process with XUL cruft. Then the argument would be that Firefox is too far behind. You can never win everybody.

kevin_thibedeau 8y ago
Taking away XUL is not the problem. Leaving users with a crippled replacement is.
gnomewascool 8y ago
"e10s compatible" add-ons were as fully-featured as the "original" XUL add-ons and did not interfere with multi-process at all. For instance, VimFx was e10s compatible and could even run with Firefox Nightly (which allowed "legacy" add-ons), without disabling multi-process, until about Firefox 65(!), without major changes.

bad_user 8y ago

As a long time Firefox user I think the change in its extensions APIs is one of the greatest moves they did and I’m glad they did it. Chrome’s extensions were isolated, easy to develop and had a permissions system in place. To this day Firefox is still lagging behind in its isolation. For example Chrome can disable extensions in Incognito, but Firefox does not. Also if you’re not paying attention, Chrome won and it’s nearly a monopoly. This means browser extensions get developed for Chrome first. Having similar APIs helps with migration. I view the change as a good thing because I can finally develop my own extensions without headaches.

JohnFen 8y ago
> As a long time Firefox user I think the change in its extensions APIs is one of the greatest moves they did and I’m glad they did it. Not me. If the new extension system didn't present a loss of important (to me) functionality, then I'd think it was a good thing. But the loss of functionality happened, and that change is what makes the new Firefox unsuitable for me, so I stopped using it (and I never used Chrome).
fiddlerwoaroof 8y ago
Isolation isn’t a benefit for extensions: the whole point of extensions, bookmarklets, etc. is to be able to modify arbitrary aspects of the browsing experience in arbitrary ways.
- Wowfunhappy 8y ago
  It's a balance, right? If browser extensions had kernel access, I think we'd all agree that's bad. Now, that's obviously an extreme, but where is the line? Up until recently†, I'm not aware of a situation where a popular Firefox extension was unable to work in Chrome due to Google restrictions. †I'm purposefully excluding the whole adblock thing, as that's super recent and thus not relevant here.
  - MrStonedOne 8y ago
    But it's not about the popular extensions. Now there is no more middle click to submit on forms and I used that at my old job to speed up a bunch of tedious tasks.
    - ZeikJT 8y ago
      That sounds trivial to implement in an extension at least. If there isn't one already I could probably take a crack at it.
  - TeMPOraL 8y ago
    > It's a balance, right? If browser extensions had kernel access, I think we'd all agree that's bad. Now, that's obviously an extreme, but where is the line? It is, and it boils down to the usual security vs. utility tradeoff - beyond some point, more secure means less useful. Kernel access is a stretch, but then again, I could make my computing experience much more pleasant if I had a deeper ability to control and inspect the browser from external software running on my computer.