4 ms·

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 goin

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...

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...