13 ms·

Looks like a lot of wont be ported, limited functionality and lack of necessary APIs on that list. Doesn't quite give me much confidence in WebExtensions.

by plopz 9y ago

nicoburns 9y ago
Note that the webextension APIs are still under active development. So just because the APIs don't exist yet doesn't mean that they won't ever.
- deleted 9y ago
  [deleted]
- iterati 9y ago
  The right thing to do would have been to work on those extensions BEFORE breaking users' experience.
  - digi_owl 9y ago
    Sadly not how the FOSS world works any longer. All that matters is the "shiny" (often wrapped in some kind of "social consciousness" claptrap), and those of us that has come to rely on existing behavior has to either suck it up, move on, or fork (And even forks struggle)...
    - amaranth 9y ago
      I don't remember the FOSS world _ever_ working like you seem to think it should. The CADT Model[1] isn't exactly new and it wasn't really new when jwz coined the term either. Only the kernel, POSIX-y things, and enterprise software provides what you're asking for. And forks of Firefox struggle because writing a browser is really really hard and they can't keep up with the changes needed. [1] https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
  - nicoburns 9y ago
    Totally agree with this. I think it was a mistake on Mozilla's part not to put more effort into extension parity before the switch-over. But I'm relatively optimistic for the future.
    - throwanem 9y ago
      Have you seen the Firefox backlog? If they'd gone for 100% API parity before the switch, we'd have had to wait another three years for e10s, and I don't know if that would have been survivable. I'm not happy about the situation as it stands, and I don't expect anyone else to be. I would be a lot more not happy about having to switch to Chrome because Firefox had become unusably slow - which it had already more or less done, before e10s started to land this year. Absent that I'd probably have had to switch already, just to be reliably able to get work done. And then there would be no one on the teams I've worked on who cared at all about maintaining Firefox compatibility, because everyone else already switched years ago. Less than ideal though the status quo be, I have a hard time seeing how any of that would be preferable.
      - MadWombat 9y ago
        > I have a hard time seeing how any of that would be preferable. Not to you. But not everyone cares about the same things. I have used Firefox as my main browser ever since it split off from Mozilla Suite. Personally, I have never, in the whole history of Firefox had a problem with its speed. At various points I might have had some problems with stability, some problems with compatibility and some problems with memory usage. But speed is just not an issue for me. Even in the "slowest" browsers most of the time is spent on network latency anyway. But I have, over the years, customized my Firefox experience to some degree. I do not do anything crazy, I don't have a zillion of extensions, but I am really used to the few I do have. And this release broke those with no sufficient replacement. And the release was distributed as automatic upgrade, so I was not even asked if I want to upgrade. A warning of some sort would be nice before breaking so much functionality. And now that the upgrade happened, there is no clear way on how to revert it. A quick google search tells me that downgrading runs a chance of corrupting my profile. I might have to risk it anyway, since after using FF57 for a day at work, I feel that my productivity and workflow are seriously impaired. At this point I am not sure whether I should stay with the LTR version of FF, switch to an FF derivative like Waterfox or change browsers altogether. The FF57 experience is so vastly different from my pre-57 workflow that I might as well be using a different browser already. There were important features to FF that kept me a loyal user through many years. Those features are gone now.
  - DiThi 9y ago
    Most of these were done by users scratching their itch. And I'm confident that's exactly why we'll get most of those experiences back.
    - CaptSpify 9y ago
      Not necessarily. WebExtensions by design don't work on firefox pages, nor do they have full access to the browser like the old addons used to have. There are a few requests our there to get the needed access added, but Mozilla is basically going to let those rot: https://bugzilla.mozilla.org/show_bug.cgi?id=1215061 https://bugzilla.mozilla.org/show_bug.cgi?id=1215061
  - Tomte 9y ago
    Mozilla doesn't create all those extensions. And the extensions' authors had, what, two years advance warning or so? Criticize the real culpits, not Mozilla.
    - wlesieutre 9y ago
      If the required WebExtension APIs don't exist (per nicoburns' comment) I'm not sure what you want the extension authors to do about it. "Complain loudly" was the strategy that got Mozilla to implement Tree Style Tabs as a WebExtension feature so that the addon could be rewritten for FF57, but there are presumably still legacy extension capabilities that haven't gotten that treatment.
    - samastur 9y ago
      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.
  - dralley 9y ago
    https://news.ycombinator.com/item?id=15696184 https://news.ycombinator.com/item?id=15696184
- doodpants 9y ago
  > Note that the webextension APIs are still under active development. In which case, switching to webextension support exclusively is premature at this point, don't you think? It would have been better to wait until the API was robust enough to allow 99.99% of legacy extensions to be ported.
  - Yoric 9y ago
    Unfortunately, this would have meant no Firefox Quantum. As a Firefox dev (I'm still working at Mozilla, although not much on Firefox atm), I have seen many, many occurrences in which I couldn't optimize codepaths, or even in some case fix bugs, because the old extension mechanism made it impossible. Consider the necessary steps: 1. realize that an internal API is broken; 2. come up with a new non-broken API; 3. port all the internal code using the non-broken API; 4. add a compatibility layer between the broken API and the non-broken API; 5. check all the existing add-ons to find out which ones use the broken API; 6. hope you didn't forget any add-on; 7. attempt to get in touch with all the add-on developers; 8. repeat 7. many, many times, until you are sure that the add-on developers that do not respond have simply abandoned their add-on; 9. negotiate a transition plan with the add-on developer with whom you have managed to get in touch; 10. land the patch that you have written now 3-4 months ago; 11. maintain both the broken API and the non-broken API (and their tests) for ~1 year, until you are reasonably sure that all add-on developers who intend to migrate have done so; 12. maintain (and test) a downgrade path for people who switch between versions of Firefox; 13. finally land your code; 14. realize that you still have accidentally broken some add-ons and people are (rightfully) unhappy because "Firefox broke my add-on"; 15. it's 18 months since you wrote your 2-lines patch, you can finally get rid of the dead code and tests and move to something else. This was one of the reasons for which the Chrome teams managed to be faster and more efficient than the Firefox teams (well, that and a bazillion dollars to hire way more people). The add-on architecture is the main reason for which projects such as multi-processes only landed ~8 years after we had working prototypes and some other performance projects never landed at all. So, yes, removing the add-on architecture is definitely painful for a number of Firefox users, but I believe that we could not postpone it any further, even if it meant that some useful addons could not be ported immediately. Also, for what it's worth, we have postponed it by something like 7 years already :)

Looks like a lot of wont be ported, limited functionality and lack of necessary APIs on that list. Doesn't quite give me much confidence in WebExtensions.

by plopz 9y ago

Looks like a lot of wont be ported, limited functionality and lack of necessary APIs on that list. Doesn't quite give me much confidence in WebExtensions.

nicoburns 9y ago

Note that the webextension APIs are still under active development. So just because the APIs don't exist yet doesn't mean that they won't ever.

deleted 9y ago
[deleted]
iterati 9y ago
The right thing to do would have been to work on those extensions BEFORE breaking users' experience.
- digi_owl 9y ago
  Sadly not how the FOSS world works any longer. All that matters is the "shiny" (often wrapped in some kind of "social consciousness" claptrap), and those of us that has come to rely on existing behavior has to either suck it up, move on, or fork (And even forks struggle)...
  - amaranth 9y ago
    I don't remember the FOSS world _ever_ working like you seem to think it should. The CADT Model[1] isn't exactly new and it wasn't really new when jwz coined the term either. Only the kernel, POSIX-y things, and enterprise software provides what you're asking for. And forks of Firefox struggle because writing a browser is really really hard and they can't keep up with the changes needed. [1] https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
- nicoburns 9y ago
  Totally agree with this. I think it was a mistake on Mozilla's part not to put more effort into extension parity before the switch-over. But I'm relatively optimistic for the future.
  - throwanem 9y ago
    Have you seen the Firefox backlog? If they'd gone for 100% API parity before the switch, we'd have had to wait another three years for e10s, and I don't know if that would have been survivable. I'm not happy about the situation as it stands, and I don't expect anyone else to be. I would be a lot more not happy about having to switch to Chrome because Firefox had become unusably slow - which it had already more or less done, before e10s started to land this year. Absent that I'd probably have had to switch already, just to be reliably able to get work done. And then there would be no one on the teams I've worked on who cared at all about maintaining Firefox compatibility, because everyone else already switched years ago. Less than ideal though the status quo be, I have a hard time seeing how any of that would be preferable.
    - MadWombat 9y ago
      > I have a hard time seeing how any of that would be preferable. Not to you. But not everyone cares about the same things. I have used Firefox as my main browser ever since it split off from Mozilla Suite. Personally, I have never, in the whole history of Firefox had a problem with its speed. At various points I might have had some problems with stability, some problems with compatibility and some problems with memory usage. But speed is just not an issue for me. Even in the "slowest" browsers most of the time is spent on network latency anyway. But I have, over the years, customized my Firefox experience to some degree. I do not do anything crazy, I don't have a zillion of extensions, but I am really used to the few I do have. And this release broke those with no sufficient replacement. And the release was distributed as automatic upgrade, so I was not even asked if I want to upgrade. A warning of some sort would be nice before breaking so much functionality. And now that the upgrade happened, there is no clear way on how to revert it. A quick google search tells me that downgrading runs a chance of corrupting my profile. I might have to risk it anyway, since after using FF57 for a day at work, I feel that my productivity and workflow are seriously impaired. At this point I am not sure whether I should stay with the LTR version of FF, switch to an FF derivative like Waterfox or change browsers altogether. The FF57 experience is so vastly different from my pre-57 workflow that I might as well be using a different browser already. There were important features to FF that kept me a loyal user through many years. Those features are gone now.
- DiThi 9y ago
  Most of these were done by users scratching their itch. And I'm confident that's exactly why we'll get most of those experiences back.
  - CaptSpify 9y ago
    Not necessarily. WebExtensions by design don't work on firefox pages, nor do they have full access to the browser like the old addons used to have. There are a few requests our there to get the needed access added, but Mozilla is basically going to let those rot: https://bugzilla.mozilla.org/show_bug.cgi?id=1215061 https://bugzilla.mozilla.org/show_bug.cgi?id=1215061
- Tomte 9y ago
  Mozilla doesn't create all those extensions. And the extensions' authors had, what, two years advance warning or so? Criticize the real culpits, not Mozilla.
  - wlesieutre 9y ago
    If the required WebExtension APIs don't exist (per nicoburns' comment) I'm not sure what you want the extension authors to do about it. "Complain loudly" was the strategy that got Mozilla to implement Tree Style Tabs as a WebExtension feature so that the addon could be rewritten for FF57, but there are presumably still legacy extension capabilities that haven't gotten that treatment.
  - samastur 9y ago
    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.
- dralley 9y ago
  https://news.ycombinator.com/item?id=15696184 https://news.ycombinator.com/item?id=15696184
doodpants 9y ago
> Note that the webextension APIs are still under active development. In which case, switching to webextension support exclusively is premature at this point, don't you think? It would have been better to wait until the API was robust enough to allow 99.99% of legacy extensions to be ported.
- Yoric 9y ago
  Unfortunately, this would have meant no Firefox Quantum. As a Firefox dev (I'm still working at Mozilla, although not much on Firefox atm), I have seen many, many occurrences in which I couldn't optimize codepaths, or even in some case fix bugs, because the old extension mechanism made it impossible. Consider the necessary steps: 1. realize that an internal API is broken; 2. come up with a new non-broken API; 3. port all the internal code using the non-broken API; 4. add a compatibility layer between the broken API and the non-broken API; 5. check all the existing add-ons to find out which ones use the broken API; 6. hope you didn't forget any add-on; 7. attempt to get in touch with all the add-on developers; 8. repeat 7. many, many times, until you are sure that the add-on developers that do not respond have simply abandoned their add-on; 9. negotiate a transition plan with the add-on developer with whom you have managed to get in touch; 10. land the patch that you have written now 3-4 months ago; 11. maintain both the broken API and the non-broken API (and their tests) for ~1 year, until you are reasonably sure that all add-on developers who intend to migrate have done so; 12. maintain (and test) a downgrade path for people who switch between versions of Firefox; 13. finally land your code; 14. realize that you still have accidentally broken some add-ons and people are (rightfully) unhappy because "Firefox broke my add-on"; 15. it's 18 months since you wrote your 2-lines patch, you can finally get rid of the dead code and tests and move to something else. This was one of the reasons for which the Chrome teams managed to be faster and more efficient than the Firefox teams (well, that and a bazillion dollars to hire way more people). The add-on architecture is the main reason for which projects such as multi-processes only landed ~8 years after we had working prototypes and some other performance projects never landed at all. So, yes, removing the add-on architecture is definitely painful for a number of Firefox users, but I believe that we could not postpone it any further, even if it meant that some useful addons could not be ported immediately. Also, for what it's worth, we have postponed it by something like 7 years already :)