[Sylos]

> Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs.

I don't know how you come to this conclusion. They've been able to maintain XUL up until now and whatever they end up with in this new API, it'll be cheaper to maintain than the monstrosity that is XUL extensions.

The specification and implementation are done in cooperation with the add-on developers. They can draw from the community here.

And while they haven't reached Chrome parity yet, they do have already implemented some additional APIs. You're writing as if one thing would block the other.

[tn123]

I get this conclusion from over a decade of add-on development, and many years of volunteering my time to/for mozilla in various capacities incl helping other add-on developers, reviewing add-ons for AMO, fixing bugs within Firefox itself, during which I became quite familiar with the code base and development process of Firefox.

PS: As to maintaining XUL vs WebExtensions API, they always maintained XUL/XPCOM themselves because that's what Firefox itself uses, meaning the entirety of Firefox developers "maintains" that "API". They regularly broke stuff for add-on developers, which was sometimes annoying, sometimes avoidable, and other times just necessary.

Some add-on developers learned to adept to that, other add-on developers switched to the add-on SDK (which like WebExtensions is a limited API, just not chrome compatible) if it was feasible, and a lot of developers will switch to the WebExtensions API if feasible in the future or even now.