6 ms·

If required APIs don't exist any more, how is that extension author's fault? (Tab Groups user here)

Tomte 9y ago
If they don't exist, sure, but most of the bickering is "I want XUL and nothing else". And how many of those lamenting the absence of some API have actually told Mozilla what they need? By all accounts Mozilla has been very responsive and helpful. Not everything was possible, but the problem lies mostly not on their side.
- throwanem 9y ago
  > most of the bickering is "I want XUL and nothing else" I don't know that that's fair. The discussions I've seen and participated in have revolved around equivalency, not identity. > how many of those lamenting the absence of some API have actually told Mozilla what they need? The Vimperator devs and some users have been very clear on that point. > Mozilla has been very responsive and helpful. Not everything was possible, but the problem lies mostly not on their side. Mozilla has indeed been responsive and as helpful as they can be given the constraints under which they operate. But extension developers aren't really to blame here either, because if WebEx doesn't include an API you can use to do what you need to do, then what option do you have? There's frustration on all sides - Mozilla devs, extension devs, and users. But we're all pulling together toward the same ultimate goal. I don't know what improvement anyone expects to elicit by trying to assign blame.
  - chimeracoder 9y ago
    > 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. Or, to put in XKCD form: https://xkcd.com/1172/ https://xkcd.com/1172/ [0] https://github.com/ChimeraCoder/electrovim https://github.com/ChimeraCoder/electrovim
    - iterati 9y ago
      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.
      - chimeracoder 9y ago
        > 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?
        iterati 9y ago
        > 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.
        throwanem 9y ago
        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.

If they don't exist, sure, but most of the bickering is "I want XUL and nothing else". And how many of those lamenting the absence of some API have actually told Mozilla what they need? By all accounts Mozilla has been very responsive and helpful. Not everything was possible, but the problem lies mostly not on their side.

throwanem 9y ago
> most of the bickering is "I want XUL and nothing else" I don't know that that's fair. The discussions I've seen and participated in have revolved around equivalency, not identity. > how many of those lamenting the absence of some API have actually told Mozilla what they need? The Vimperator devs and some users have been very clear on that point. > Mozilla has been very responsive and helpful. Not everything was possible, but the problem lies mostly not on their side. Mozilla has indeed been responsive and as helpful as they can be given the constraints under which they operate. But extension developers aren't really to blame here either, because if WebEx doesn't include an API you can use to do what you need to do, then what option do you have? There's frustration on all sides - Mozilla devs, extension devs, and users. But we're all pulling together toward the same ultimate goal. I don't know what improvement anyone expects to elicit by trying to assign blame.
- chimeracoder 9y ago
  > 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. Or, to put in XKCD form: https://xkcd.com/1172/ https://xkcd.com/1172/ [0] https://github.com/ChimeraCoder/electrovim https://github.com/ChimeraCoder/electrovim
  - iterati 9y ago
    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.
    - chimeracoder 9y ago
      > 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?
      - iterati 9y ago
        > 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.
      - throwanem 9y ago
        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.