[tn123]

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.

So far, Firefox did not even manage to reach chrome parity, let alone bug parity.

If you look at the Advisory Group meeting notes (in charge of new APIs AFAIK), there is almost nothing still: https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeu...

Sorry David, but you're kidding yourself here.

[hackuser]

From Giorgio Maone, developer of one of the most complex and most popular extensions, NoScript:

Developers and users are also concerned about add-ons being prevented from exploring radically new concepts which would require those "super powers" apparently taken away by the WebExtensions API.

I'd like to reassure them: Mozilla is investing a lot of resources to ensure that complex and innovative extensions can prosper also in the new Web-centric ecosystem. In fact, as mentioned by Bill McCloskey, at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API, which is going to be augmented and shaped around their needs and with their contributions.

https://hackademix.net/2015/08/22/webextensions-api-noscript...

[tn123]

From Nils Maier, developer of some of the most complex and most popular extensions, DownThemAll! (+ MinTrayR): Read my comments

That comment by Giorgio (nice guy btw, shared a room with him on at a couple of mozilla events) is over a year old by now and rather optimistic. So far, nothing of that happened, nor will it ever happened at a scale that actually accommodates most add-on developers.

[hackuser]

> So far, nothing of that happened

He wrote that it was already happening a year ago: at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API

I'm not an add-on developer but I've read about it happening in other places too, and I know for a fact that Giorgio is working on Firefox WebExtensions issues in Bugzilla.

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