This article really doesn't match my recollection of how things went down. It implies that the switch to a multi-process model (Electrolysis/e10s) was held up pending the switch to WebExtensions. But I'm pretty sure I remember a transition period during which all my XUL-based extensions were either rewritten to support multiprocess or deprecated, which was years before XUL extensions were actually killed in favor of the less-capable WebExtensions. The article talks about this like it's a path they rejected, even though I'm pretty sure it actually happened. That transition was also a lot less painful than the switch to WebExtensions: over a period of several browser releases, I watched as the list of extensions preventing my browser from turning on the multiprocess capability dwindled. All the most important and popular extensions I was using made the switch smoothly with no major user-facing changes in capability or UI, which is the exact opposite of how the WebExtensions switch went.
It would really help if this article could use dates and/or version numbers to establish the timeline of events it's talking about.
(article author) Thanks for the feedback, I've just updated this part of the article to clarify it. I don't remember exact dates, though, so I won't be able to add them.
But yes, you are right, there was a time during which a number of old-style extensions were ported to be compatible with e10s. It was possible for some, impossible for others, hard when it was possible, and most add-on developers didn't port them, either because it was too difficult or because they had grown tired or the _maintenance tax_ I mention.
And yet, after they had ported their add-ons to be e10s-compatible, the add-ons broke nevertheless, one by one, for all the reasons mentioned in the article.
You threw in the towel before your most important extension developers did. Well-maintained popular extensions like NoScript and TreeStyleTab remained functional throughout the e10s transition with fixes delivered before the breaking changes in Firefox made it to stable releases, but they were irreparably harmed by the WebExtension transition. Their WebExtension versions are still not up to feature parity, despite ongoing maintenance.
It's quite obvious that the WebExtension model is better for users and developers of simple extensions. But it continues to not be an adequate substitute for the kind of extensions that gave Firefox real advantages over Chrome and other browsers. It's not at all apparent why those advanced, killer app extensions had to die in order to get the bulk of the extension ecosystem moved over to WebExtensions.
The author of NoScript was part of way more meetings than me during the design of the WebExtensions API, so he would probably be able to tell you more about what happened to his add-on.
> But I'm pretty sure I remember a transition period during which all my XUL-based extensions were either rewritten to support multiprocess or deprecated, which was years before XUL extensions were actually killed in favor of the less-capable WebExtensions.
It wasn't really years. Electrolysis went live in spring 2017 (it came with Fx 48 and was gradually activated till Fx54). Around that time was the first massextinction of addons.
WebExtensions and Firefox Quantum then came in autonm 2017 with Fx 57, finalizing the bigger second massextinction.
> Electrolysis went live in spring 2017 (it came with Fx 48 and was gradually activated till Fx54). Around that time was the first massextinction of addons.
Ok, so power users that mess with about:config (or users with zero extensions) were running e10s for more than a year before the WebExtension switch, and e10s was available in the beta and nightly channels long before then (ie. by late 2015).
But what's really important is that the process of enabling e10s was gradual and well-managed from a user perspective, rather than being a singular event that broke almost every extension long before viable replacements could be developed for most of them.
It would really help if this article could use dates and/or version numbers to establish the timeline of events it's talking about.