On Wed, Jul 26, 2017 at 4:27 PM, Steve Fink <sf...@mozilla.com> wrote:
> This thread worries me greatly. Somebody tell me we have a plan and policy > around this already. Please? > We might, but I'm not sure what "this" you're concerned about. Whether API names should be prefixed? Or whether we should expose things at all that are unique to gecko/firefox to extensions? There are a whole bunch of things that get considered when new extension APIs are proposed including safety, maintainability, performance, and yes, cross-browser compatibility. Unfortunately, there isn't anything written that explains actual criteria in detail (its on our radar but somewhere behind a long list of engineering tasks on the short-term priority list). My individual opinion is that something being unique to gecko or firefox should not disqualify it from being exposed to extensions. The webcompat analogy doesn't really work here, the principle that the web should be open and interoperable demands rigor in what gets exposed to content. But a browser extension isn't a web page, it is part of the browser itself, and different browsers are inherently ... different. They have different features, different user interfaces, etc. The fact that browser extensions are built with web technology and that they modify or extend the very thing that displays web content obscures this distinction, but it does make a big difference. Anyway, containers is a good example of something that we've exposed to extensions that isn't likely to be supported in other browsers any time soon. Nevertheless, we need to design APIs in a way that doesn't compromise on the other areas mentioned above: maintainability, safety, performance. And, to the extent we can, we should design APIs that could be adopted by other browsers if they choose to. > Given our position, it's a bold move that says we're willing to take the > painful hit of pissing off addon authors and users because we truly believe > it is necessary to produce a top-quality product. There are certainly outraged addon authors out there but for what its worth, we're also already getting a good amount of positive feedback from both addon authors and users. That's my argument for why the default answer here should be "Heck yeah! If > we can provide something that other browsers don't, DO IT!" I could > describe it as a fairness/good faith argument instead: we just took away a > bunch of powerful tools from our users, claiming that it was for their own > long-term good, so it behooves us to give back whatever we can in a more > manageable form, in order to provide that promised good. > I think that's basically the attitude of most of the people working on webextensions. To be pedantic, the threshold is higher than "If we can". I mean, we *could* expose Components to webextensions but of course that would bring us right back to all the problems we're working on putting behind us. Again, documenting more formally specifically what it means for an extension API to be safe, maintainable, performant, etc. is something we know is needed. Hopefully when we come up for air after 57 we can work on this (and complementary things like webextensions experiments). -Andrew _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
