> I don't know that that's fair. The discussions I've seen and participated in have revolved around equivalency, not identity.
I've developed a couple of Firefox extensions. One of those was an e10s-compatible replacement for Vimperator, because Vimperator relied on XUL[0]. (Vimperator broke long before Firefox 57, because e10s broke backwards compatibility with some extensions long before Firefox 57 did).
The old extensions "API" was essentially a way to plug into arbitrary parts of the Firefox codebase. A Firefox developer has previously said that "[previously] the entire codebase was our extensions API".
That's not scalable or maintainable in the long-run, and I would assume that any software developer who's worked on a moderately-large project would appreciate that allowing arbitrary entrypoints and coupling makes it impossible to do literally anything without breaking some part of that extremely ill-defined API.
It's really, really unfortunate that moving towards a modern approach to browser extensions meant breaking work that people had put in over the last fifteen years, but... there's literally no other way to do it. Firefox was the first non-experimental browser to allow browser extensions, and there are both benefits and costs to being first-to-market. In this case, the downside is that they ended up accruing this technical (maintenance) debt.
As someone who's written Firefox extensions that are no longer available due to the switch, I'm disappointed that this had to happen. But as a Firefox user, I'm much happier having Quantum and Electrolysis (e10s), and if the tradeoff is between those two directly, I'd choose Quantum + Electrolysis over those extensions.
By "equivalency" I mean having access to equivalent APIs for specific functionality, as for example the inability to listen for window events that's breaking Vimperator and friends. (And electrovim! Have you noticed that it stops working on chrome pages that don't run scripts? Has the CSP bug been fixed? I didn't think it had been.)
Maybe it's not possible to support window event listeners without breaking e10s. But I see no a priori reason why it should be.
I haven't seen anyone in a serious discussion demanding 100% XUL API compatibility or feature coverage. (For the purposes of this comment, most discussion of the issue on HN is unserious.)
"As someone who's written Firefox extensions that are no longer available due to the switch, I'm disappointed that this had to happen. But as a Firefox user, I'm much happier having Quantum and Electrolysis (e10s), and if the tradeoff is between those two directly, I'd choose Quantum + Electrolysis over those extensions."
Well, I'm a Firefox user, not an extension developer, and Pentadactyl happened to be one of the extensions that made using Firefox bearable. Now that it's permanently broken, I'll be moving to another browser which can offer a similar experience: Qutebrowser.[1]
> Well, I'm a Firefox user, not an extension developer, and Pentadactyl happened to be one of the extensions that made using Firefox bearable. Now that it's permanently broken,
Pentadactyl was all-but-abandoned for years before Vimperator was broken. It's been almost four years since it saw a release - which was for Firefox 24.0-30[0]. Its website still links at least three links to code.google.com on the front page! (I'm actually shocked if Pentadactyl has even been working for you until now, given that it was supposed to break a few release cycles ago - when e10s shipped - but maybe you just haven't updated Firefox in a while, or you manually disabled e10s.)
Vimperator - which is also incompatible with Firefox 55+ for the same reasons Pentadactyl is - at least has been receiving maintenance attention in the meantime[1], and also provides alternatives for use with Firefox 55+ (and 57+).
If you'd rather switch browsers entirely than use something like Vimium[2] on Firefox, go ahead, but it's hard to justify holding an entire browser back just to maintain compatibility with an extension that has been abandoned by its own maintainers. As I mentioned, I can't even reasonably expect them to hold Firefox back to maintain compatibility with the extensions I wrote and actively maintained. As a Firefox developer, I'm disappointed, but as a Firefox user, I'm more than happy enough with the changes to make up for it.
Despite there being no official releases in years and being abandoned by its official developers, Pentadactyl was kept afloat by its users, from whom you could still get fixes and releases through google code and google groups. I also fixed some things for myself, based on help from the community. Despite all this, it did finally completely break recently (before FF 57), and I just had to not update FF for a while until I found an alternative. I used PaleMoon for a while, but now I'm switching to Qutebrowser.
"it's hard to justify holding an entire browser back just to maintain compatibility with an extension that has been abandoned by its own maintainers"
Pentadactyl was far from the only extension that Firefox decided to break. Many other extensions were affected.
As far as Pentadactyl itself went, the reason its maintainers abandoned it was because Firefox kept breaking compatibility with it over, and over, and over, and over. They understandably got frustrated by that and moved on to other things.
Then, when Firefox put their foot down and announced that they'd be changing the browser so that Pentadactyl will never again be able to work on it, no matter what its developers did, a lot of people didn't see the point of putting more effort in to. It survived only because of the dedication and help of the remaining community. Now there's nothing even they can do. Not with Firefox anyway. So we're moving on to something else.
I think that's a great point: it's difficult, near impossible, to make any particular piece of software contain 100% of the features that 100% of people want. Especially in the case of a tiny-minority feature, a specialized version that caters to your needs sometimes makes the most sense.
I just worry that people using some of these alternative browsers are opening themselves up to security issues since those code bases are less well-tested for security problems, and often they don't have the developer resources to implement things like process isolation and sandboxing.
> I just worry that people using some of these alternative browsers are opening themselves up to security issues since those code bases are less well-tested for security problems
Absolutely. The web browser is one of the most notorious attack vectors on computers these days. I find it hilarious that a vocal minority of power users is protesting this _massively impressive_ Firefox release just because they lost Tree Style Tabs or some extensions for downloading videos. Switching to a legacy fork like Waterfox or Firefox 52 ESR is not an enlightened move!
Well, I'm a Firefox user, not an extension developer, and I much prefer a performant browser with modern security features (and the ability to implement more in the future, which they couldn't do pre-57). I've lost a couple extensions during the move, but the tradeoff is well worth it to me.
And it sucks that you don't feel that way -- it really does -- but I suspect the vast majority of Firefox users feel as I do, and in the end Mozilla needs to cater to the most users possible.
electrovim is in no way a replacement for Vimperator. It's a couple of keyboard shortcuts. None of the current vim-like plugins for FF57 match what vimperator/pentadactyl can do. The problem I have isn't that they broke legacy things, it's that they broke legacy things without offering a path to rebuild them.
> electrovim is in no way a replacement for Vimperator. It's a couple of keyboard shortcuts. None of the current vim-like plugins for FF57 match what vimperator/pentadactyl can do.
Uh, yes, I'm the author of Electrovim, so I'm quite aware of the functionality that I was literally unable to implement because no equivalent API existed.
> The problem I have isn't that they broke legacy things, it's that they broke legacy things without offering a path to rebuild them.
Did you not read the rest of the comment, where I explain why there is no feasible way that they could have offered any path to rebuild them?
> I've developed a couple of Firefox extensions. One of those was an e10s-compatible replacement for Vimperator, because Vimperator relied on XUL[0].
Replacement for Vimperator implies it's, well, a replacement for Vimperator.
> Did you not read the rest of the comment, where I explain why there is no feasible way that they could have offered any path to rebuild them?
I don't see how your addressed that. Yes, existing extensions that used XUL would have to be rewritten using new APIs. My issue is that those APIs don't even exist. That there are good reasons the old APIs aren't available anymore doesn't address the lack of new APIs that offer anything near equivalent functionality.
Is it impossible to support window or otherwise chrome-level event listeners and also e10s? As I said in a prior comment, there seems no a priori reason that should be the case.
> Is it impossible to support window or otherwise chrome-level event listeners and also e10s?
Yes, because those things are now running in different processes, which means it requires IPC, and allowing extensions to communicate over IPC with the chome throws all the benefits of e10s out the window.
It looks like it's been broken down into a number of separate issues since then, and there's some discovery yet to be done on how exactly the implementation will need to proceed - I feel like Firefox 58 is very optimistic, but I also feel like saying "this is never going to happen" is pretty premature at this point. At the very least, the Firefox devs don't seem to agree.
I've developed a couple of Firefox extensions. One of those was an e10s-compatible replacement for Vimperator, because Vimperator relied on XUL[0]. (Vimperator broke long before Firefox 57, because e10s broke backwards compatibility with some extensions long before Firefox 57 did).
The old extensions "API" was essentially a way to plug into arbitrary parts of the Firefox codebase. A Firefox developer has previously said that "[previously] the entire codebase was our extensions API".
That's not scalable or maintainable in the long-run, and I would assume that any software developer who's worked on a moderately-large project would appreciate that allowing arbitrary entrypoints and coupling makes it impossible to do literally anything without breaking some part of that extremely ill-defined API.
It's really, really unfortunate that moving towards a modern approach to browser extensions meant breaking work that people had put in over the last fifteen years, but... there's literally no other way to do it. Firefox was the first non-experimental browser to allow browser extensions, and there are both benefits and costs to being first-to-market. In this case, the downside is that they ended up accruing this technical (maintenance) debt.
As someone who's written Firefox extensions that are no longer available due to the switch, I'm disappointed that this had to happen. But as a Firefox user, I'm much happier having Quantum and Electrolysis (e10s), and if the tradeoff is between those two directly, I'd choose Quantum + Electrolysis over those extensions.
Or, to put in XKCD form: https://xkcd.com/1172/
[0] https://github.com/ChimeraCoder/electrovim