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

[thrdbndndn]

>how much is enough

They used to have an official goal like "supporting top X addons' transitions", so it's not so random about which API they needed to add.

[gnomewascool]

> There were operating systems which took the approach XPCOM has to extensibility, they're not doing so great

The Emacs OS is still doing well! :)

> "Mozilla did kill XPCOM" isn't a deviation from their stated intent.

The issue is that their stated intent changed over time, and their communication about their precise intentions was often pretty poor.

It didn't help that the Webextension transition came on the heels of the e10s transition (5 firefox versions separated deprecating non-e10s add-ons and disabling e10s add-ons), but with relatively little warning, which meant that:

1. Many people implicitly believed that once they adapted their addons for e10s, they'd be safe.

2. Many people put in a huge amount of work to adapt for e10s and then had to redo a large part of it to convert their add-on into a webextension.

3. Some people put in a huge amount of work to adapt for e10s and found out that their work was pointless because their add-ons couldn't be converted into webextensions.

From a technical point of view, much of Firefox's XPCOM/internals were actually sufficiently stable post-webextension (57) that old e10s extensions could have continued to work with little changes. (e.g. VimFx continued to work with minimal changes for ~30 Firefox versions, on Nightly, with very slight hacking. AFAICT it still continues to work, with slight changes, but now with major hacking to get it to actually install.)