7 ms·

Very few people are bothered by the movement to WebExtensions, multi-process, or removal of complete themes. Many, however, have stopped using the browser as i

Very few people are bothered by the movement to WebExtensions, multi-process, or removal of complete themes. Many, however, have stopped using the browser as it has felt slow and clunky for quite a while now. The recent changes have actually attracted me back to the platform after a decade of using Chrome.

51Cards 9y ago
I am however one of those. While I understand the technical reasons for the switch I don't think it has been handled well. Extensions I rely on daily are going to cease functioning because the WebExtensions API isn't mature enough for the developers to migrate. Are they going to wait? Probably not... most affected will probably abandon their projects because FF rushed the transition and their user base is about to drop off a cliff due to no fault of their own. I would feel pretty abandoned.
- KGIII 9y ago
  Rushed? It was announced more than two years ago, as I recall. Hmm... August, 2015.
  - 51Cards 9y ago
    When it was announced is somewhat irrelevant. Developers are saying Web Extensions still isn't able to support the needed functionality. That needed to be addressed before shutting down the older APIs. That is where I feel developers have been left hanging... given a "shutdown" date when the replacement isn't even ready yet.
- 482794793792894 9y ago
  They had to sort of rush it, because they wanted to rush out multiprocess, to stop the bleeding of users (which has very much worked [1]). And then they needed to follow up with the switch to WebExtensions relatively quickly, so that extension authors wouldn't start porting their extensions to multiprocess and then after that effort have to rewrite their extensions to be WebExtensions-compatible. They wanted extension authors to be able to just directly port to WebExtensions. And I do think that a lot more extension authors would have probably abandoned their projects, if they had just ported to multiprocess and then had to port to WebExtensions. Also, a lot of extensions sort of just continue to function without active maintenance. Those are why it would have just as well been really disruptive to space out multiprocess and WebExtensions by a few years. Then we'd have to start over at 0 extensions twice. [1] Multiprocess was rolled out in Firefox 48, on the 2nd August 2016: http://netmarketshare.com/report.aspx?qprid=1&qpaf=&qpcustom=Firefox&qpcustomb=0&qpsp=200&qpnp=24&qptimeframe=M http://netmarketshare.com/report.aspx?qprid=1&qpaf=&qpcustom...
  - pseudalopex 9y ago
    Developers can't port to APIs that don't exist. Mozilla holding to the November deadline as implementation has slipped hasn't helped them in any way. Mozilla kept pushing developers to make their XUL extensions multiprocess-compatible even after WebExtensions was announced. At one point, they were going to keep the multiprocess compatibility shims until the WebExtensions deadline, but then they decided to start removing them sooner.[1] SDK extensions were mostly multiprocess-compatible already. Developers are currently maintaining multiple branches of their extensions because 52 ESR is missing APIs and 57+ won't support hybrid extensions. Aligning the WebExtensions transition with the ESR cycle would have made things a lot easier for them. [1] https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/ https://blog.mozilla.org/addons/2017/02/16/the-road-to-firef...
jd3 9y ago
I am going to write up some extremely long-winded rant in blog form at some point before the FF57 release materializes, but suffice it to say, most developers that I know who have been involved with Mozilla since the Netscape days (and also those who build most of the add-ons/products that I care about, such as SeaMonkey) have shown nothing but disappointment at Mozilla's reckless plan for the Firefox 57 release. Literally just read the developer comment response to almost any Mozilla blog post about web-extensions/complete themes from the past ~year and you'd see that more than "Very few people" are bothered by this. Perhaps normal users don't care (or just haven't noticed yet), but most of the features which make the Mozilla platform so enticing to power users (what ever happened to XULRunner?) are being decimated because Mozilla is losing market-share and needs free advertising. Let's not beat around the bush; Mozilla is losing market-share because people get flustered into downloading chrome due to that Microsoft-tier advert that gets plastered onto the google search page in any non-Chrome browser. Yes, Firefox had been feeling chuggier and bloated for awhile, but the core feature-set that made the platform a dream to use for power users never waned. Speeding up the browser while retaining its core feature-set are not mutually exclusive conditions. I think that if these "normal" users understood how powerful complete themes and the XUL/XPCOM apis are, they would be up in arms. It's not that people don't want complete themes, for example. Were it not for Mozilla's incompetence (there's a bug somewhere that tracks how the total reported download count for complete themes was inexplicably reduced to just 10% of what it previously was, never recovering; there used to be hundreds of thousands of users of complete themes around ~2007-2009), such as the time wasted making incessant changes to the core browser theme that nobody asked for (nothing has ever looked as good as the Suite/SeaMonkey), is what has truly been the cause of these 'modernizations.' XUL and the add-on SDK are so powerful that I basically re-created two old unix programs ('picons newscheck-faces' and 'xfaces' [0]) over the past couple of weeks. This simple XUL/XPCOM project of mine now brings an incredibly fast & powerful cross-platform solution to two of my favorite old mail visualization programs that have suffered extreme bit rot (I swear more people used Plan 9's vismon than the verious picons/faces programs). When the legacy add-on api removal finally hits SeaMonkey, my whole extension will cease to function. In fact, it doesn't even work in the current SeaMonkey 2.54a1 nightly. Can you explain to me a similar cross-platform browser/mail client that provides similar APIs for me to rebuild my extension? The answer is no, because in a couple of months the one that did will no longer exist. Anyway, my point is that I'm not exactly sure who Mozilla is targeting with the Firefox 57 release — perhaps their jet-setting upper management; perhaps nobody. [0]: http://kinzler.com/picons/ftp/demo/ http://kinzler.com/picons/ftp/demo/ https://i.imgur.com/EnDMKuO.png https://i.imgur.com/EnDMKuO.png https://i.imgur.com/k40BISq.png https://i.imgur.com/k40BISq.png https://i.imgur.com/lvv9REm.jpg https://i.imgur.com/lvv9REm.jpg (features not even pictured above: Face header decoding, X-Face header decoding, X-Image-URL header, and Contact Card Image support) edit: also, as the one guy that has been updating the internal chrome:// url page in recent years, show me a browser that gives this amount of access to its internal tools: http://kb.mozillazine.org/Chrome_URLs#early_Mozilla_Suite_and_SeaMonkey_1.0.2F1.1 http://kb.mozillazine.org/Chrome_URLs#early_Mozilla_Suite_an...

51Cards 9y ago

I am however one of those. While I understand the technical reasons for the switch I don't think it has been handled well. Extensions I rely on daily are going to cease functioning because the WebExtensions API isn't mature enough for the developers to migrate. Are they going to wait? Probably not... most affected will probably abandon their projects because FF rushed the transition and their user base is about to drop off a cliff due to no fault of their own. I would feel pretty abandoned.

KGIII 9y ago
Rushed? It was announced more than two years ago, as I recall. Hmm... August, 2015.
- 51Cards 9y ago
  When it was announced is somewhat irrelevant. Developers are saying Web Extensions still isn't able to support the needed functionality. That needed to be addressed before shutting down the older APIs. That is where I feel developers have been left hanging... given a "shutdown" date when the replacement isn't even ready yet.
482794793792894 9y ago
They had to sort of rush it, because they wanted to rush out multiprocess, to stop the bleeding of users (which has very much worked [1]). And then they needed to follow up with the switch to WebExtensions relatively quickly, so that extension authors wouldn't start porting their extensions to multiprocess and then after that effort have to rewrite their extensions to be WebExtensions-compatible. They wanted extension authors to be able to just directly port to WebExtensions. And I do think that a lot more extension authors would have probably abandoned their projects, if they had just ported to multiprocess and then had to port to WebExtensions. Also, a lot of extensions sort of just continue to function without active maintenance. Those are why it would have just as well been really disruptive to space out multiprocess and WebExtensions by a few years. Then we'd have to start over at 0 extensions twice. [1] Multiprocess was rolled out in Firefox 48, on the 2nd August 2016: http://netmarketshare.com/report.aspx?qprid=1&qpaf=&qpcustom=Firefox&qpcustomb=0&qpsp=200&qpnp=24&qptimeframe=M http://netmarketshare.com/report.aspx?qprid=1&qpaf=&qpcustom...
- pseudalopex 9y ago
  Developers can't port to APIs that don't exist. Mozilla holding to the November deadline as implementation has slipped hasn't helped them in any way. Mozilla kept pushing developers to make their XUL extensions multiprocess-compatible even after WebExtensions was announced. At one point, they were going to keep the multiprocess compatibility shims until the WebExtensions deadline, but then they decided to start removing them sooner.[1] SDK extensions were mostly multiprocess-compatible already. Developers are currently maintaining multiple branches of their extensions because 52 ESR is missing APIs and 57+ won't support hybrid extensions. Aligning the WebExtensions transition with the ESR cycle would have made things a lot easier for them. [1] https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/ https://blog.mozilla.org/addons/2017/02/16/the-road-to-firef...

jd3 9y ago

I am going to write up some extremely long-winded rant in blog form at some point before the FF57 release materializes, but suffice it to say, most developers that I know who have been involved with Mozilla since the Netscape days (and also those who build most of the add-ons/products that I care about, such as SeaMonkey) have shown nothing but disappointment at Mozilla's reckless plan for the Firefox 57 release. Literally just read the developer comment response to almost any Mozilla blog post about web-extensions/complete themes from the past ~year and you'd see that more than "Very few people" are bothered by this. Perhaps normal users don't care (or just haven't noticed yet), but most of the features which make the Mozilla platform so enticing to power users (what ever happened to XULRunner?) are being decimated because Mozilla is losing market-share and needs free advertising. Let's not beat around the bush; Mozilla is losing market-share because people get flustered into downloading chrome due to that Microsoft-tier advert that gets plastered onto the google search page in any non-Chrome browser. Yes, Firefox had been feeling chuggier and bloated for awhile, but the core feature-set that made the platform a dream to use for power users never waned. Speeding up the browser while retaining its core feature-set are not mutually exclusive conditions. I think that if these "normal" users understood how powerful complete themes and the XUL/XPCOM apis are, they would be up in arms. It's not that people don't want complete themes, for example. Were it not for Mozilla's incompetence (there's a bug somewhere that tracks how the total reported download count for complete themes was inexplicably reduced to just 10% of what it previously was, never recovering; there used to be hundreds of thousands of users of complete themes around ~2007-2009), such as the time wasted making incessant changes to the core browser theme that nobody asked for (nothing has ever looked as good as the Suite/SeaMonkey), is what has truly been the cause of these 'modernizations.' XUL and the add-on SDK are so powerful that I basically re-created two old unix programs ('picons newscheck-faces' and 'xfaces' [0]) over the past couple of weeks. This simple XUL/XPCOM project of mine now brings an incredibly fast & powerful cross-platform solution to two of my favorite old mail visualization programs that have suffered extreme bit rot (I swear more people used Plan 9's vismon than the verious picons/faces programs). When the legacy add-on api removal finally hits SeaMonkey, my whole extension will cease to function. In fact, it doesn't even work in the current SeaMonkey 2.54a1 nightly. Can you explain to me a similar cross-platform browser/mail client that provides similar APIs for me to rebuild my extension? The answer is no, because in a couple of months the one that did will no longer exist. Anyway, my point is that I'm not exactly sure who Mozilla is targeting with the Firefox 57 release — perhaps their jet-setting upper management; perhaps nobody. [0]: http://kinzler.com/picons/ftp/demo/ http://kinzler.com/picons/ftp/demo/ https://i.imgur.com/EnDMKuO.png https://i.imgur.com/EnDMKuO.png https://i.imgur.com/k40BISq.png https://i.imgur.com/k40BISq.png https://i.imgur.com/lvv9REm.jpg https://i.imgur.com/lvv9REm.jpg (features not even pictured above: Face header decoding, X-Face header decoding, X-Image-URL header, and Contact Card Image support) edit: also, as the one guy that has been updating the internal chrome:// url page in recent years, show me a browser that gives this amount of access to its internal tools: http://kb.mozillazine.org/Chrome_URLs#early_Mozilla_Suite_and_SeaMonkey_1.0.2F1.1 http://kb.mozillazine.org/Chrome_URLs#early_Mozilla_Suite_an...