[gnomewascool]

I also was and still am disappointed about both changes, but I don't think you're being at all fair to Mozilla.

In both transitions, Mozilla made sure to support the needs of both uBlock origin and NoScript, extending the webextension API (such that uBlock origin on Firefox is more capable than on current Chromium) and working with uBlock to make its interface more mobile-friendly.

They also extended the webextension API to allow for extensions such as Treestyle tabs and Panorama-reimplementations (so not remotely all XUL use-cases, but still most of the popular ones).

Hence, they've proven that they will go considerably beyond what Google/Chromium are doing, and that they won't harm "content-blockers", which is what we care about in this case.

[chrismorgan]

I’d say fairness also requires mentioning how the browser has been able to improve because of killing off XUL extensions; technologically, they were holding things back. Firefox is considerably faster than would have been possible without breaking a great many XUL extensions anyway. And more secure, if you care about that kind of thing, which normal people probably do or should, but frankly it’s the performance I care more about. So this is a “yeah, it’s a pity, but there were good reasons and you have benefited from it, even as you suffered” kind of thing.

Also how much more reliable long-term extension/browser compatibility has improved: I’ve used Firefox Nightly as my daily driver for about ten of the last twelve years, and until 2017 I’d spot at least one or two breakages each year, mostly fairly minor, but the occasional major (a couple of which accounted for maybe six months of going back to stable—and the lead-up to the killing of XUL extensions was another few months on stable because not all that I wanted was ready on WebExtensions yet). The extensions were typically patched before the change hit stable Firefox, so normal users wouldn’t notice most. But since WebExtensions, I don’t recall a single breakage. I acknowledge that the biggest breakages were in functionality that cannot be replicated any more, like Pentadactyl (and I ended up not even trying to replace it), but still, the minor and subtle breakages are just gone.

[cycomanic]

Regarding pentadactyl, I'm using tridactyl on Firefox and essentially for all my use cases it behaves the same as pentadactyl. I realise that some of the advanced functionality of pentadactyl is not available (IIRC pentadactyl allowed you to essentially reprogram the browser), but I have to say I'm not really missing much.

[babypuncher]

I think people forget how slow and buggy Firefox used to be. There is a reason that Chrome took off like a rocket in the early '10s.

[thrdbndndn]

When the transition from XPCOM to WebExt started, Mozilla made some big promises about the functionality parity about the two but failed to deliver most of them (and silently removed such promises from their official pages, and left relevant Bugzilla tickets rot (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1427928 )).

IMHO, practically speaking, the final result of WebExt isn't that bad, especially taking into consideration of the added APIs you mentioned.

It is the shear difference bwtween promise and reality that really hurts lots of power users and addon developers to this day.

Also you mentioned Treestyle as "most of the popular ones", but left out the elephant in the room, Tab Mix Plus, which even has its own Bugzilla ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1226546 Gesture extensions nowadays are also pretty limited compared to its heyday due to the nature of WebExt.

In hindsight, these promises were just too good to be true, but people were believing.

And the story of extension support on Firefox on Android is way too similar to the last time in the Fennec to Fenix transition. At least this time, users just didn't have much faith in it to begin with.

[Multicomp]

> I don't think you're being at all fair to Mozilla

> In both transitions, Mozilla made sure [to keep top popular addons mostly happy and ensure adblockers are happy]

Those are all fair points, and yes, I was probably too harsh with my language overall, that post written before I was corrected that Mozilla was not developing MV3 the same as Google was.

I stand by my strikes that Mozilla did kill XPCOM, and failed to deliver their promise to release all addons to Fenix on shipping stable versions. They don't even enable about:config on stable Fenix to enable power users to workaround that limitation.

In short, I believe I was 60% fair in my opinion.

[tialaramex]

"Mozilla did kill XPCOM" isn't a deviation from their stated intent. XPCOM was a magnet for Hyrum's Law problems, because obviously XPCOM plugins are going to depend on the inner workings of the browser, that's just how XPCOM is designed - so now if you touch these internals it breaks third party stuff. There were operating systems which took the approach XPCOM has to extensibility, they're not doing so great: Classic Mac OS, the Amiga Workbench, MS DOS... That's just not a sustainable situation, Mozilla had to kill XPCOM.

So to the extent Mozilla failed to deliver here it's on the replacement APIs. But how much is enough?

I would like lots of things to have APIs that don't. For example I'd like a way to do some basic queries on the built-in Public Suffix List for Firefox instead of needing to either bake the PSL into each plugin (and keep it up to date) or call out to a web API (ugh) or just guess that TLDs are "enough" and make everybody who needs other suffixes mad.

But in that particular case there are two reasons we don't have such APIs. #1 Nobody did the work. I didn't do the work, you didn't do the work, the work didn't get done. #2 In many cases (I think not mine but it's always arguable) the PSL is the Wrong Thing™ and so encouraging more use of the PSL makes things worse.