I believe that Gabor's response to the original question nicely captures the thinking and plans of everybody working on WebExtensions day-to-day. The questions about formally defining a policy for what to expose to extensions and about how to (or if we should) distinguish Firefox-specific APIs from cross-platform APIs are ones that we have talked about a little bit but we've been heads-down on our goals for the breadth, stability, and performance of WebExtensions for 57 when we turn off legacy extensions.
For handling cross-platform versus Firefox-specific APIs, I don't think the right outcome is perfectly clear. Of course we should learn from how web-exposed APIs evolved and avoid the need for the browser extensions equivalent of jquery. On the other hand, browser extensions by their nature work with features that are not standardized and that differ from browser to browser. For instance, we have WebExtensions APIs for working with containers. There's no doubt in my mind that we should have this API but of course extensions that use it won't work in other browsers. Maybe in this case some sort of moz- prefix would be appropriate but its not hard to come up with murkier examples. What about the tabs API? It is currently supported in Firefox, Chrome, Edge, and Opera. But what if one of the non-tab-based-browser-ui projects takes off and wants to support browser extensions? If they simply don't support the tabs API then how should the API be named to indicate to extension developers that it isn't universally available? We're just reaching the point where it is feasible to build interesting cross-browser extensions and extension authors are starting to ask us to make it easier to do so. We've got plenty of other simple things we can do to make their lives easier (for instance extensions APIs in Chrome all use callbacks, in Firefox they can use Promises or callbacks, and in Edge they only use Promises) but this problem of naming/disocvering/etc APIS is a big architectural issue to work out. Hopefully when the dust begins to settle on 57 we can put some energy into this. For anybody who's interested, we have the dev-addons mailing list and the #webextensions IRC channel for Mozilla-specific discussion and the w3c browserext group ( https://browserext.github.io/) for cross-vendor efforts. Finally, to circle back once again to smaug's original question, I think we can be more liberal with exposing APIs to extensions than we are with exposing them to content -- enabling cross-browser extensions is an important benefit of WebExtensions but limiting WebExtensions APIs to only those that can run in every browser has never been a goal (in spite of what you may have read on hacker news). If we overdo it, we even have a draft of a policy for deprecating APIs: https://wiki.mozilla.org/WebExtensions/DeprecationPolicy I think its much more important that we take care when designing extension-facing APIs to ensure that extensions can't do anything "dangerous" by default and that they are granted access to sensitive parts of the browser, only when we can explain very clearly to a user so that they can make an informed choice whether to grant permission or not. -Andrew On Tue, Jul 25, 2017 at 2:14 AM, smaug <sm...@welho.com> wrote: > Hi all, > > > recently in couple of bugs there has been requests to add Gecko specific > APIs for extensions. > It isn't clear to me why, and even less clear to me is what the plan is > there. > I thought WebExtensions should work in several browsers, but the more we > add Gecko specific APIs, the less likely > that will be. > > Could someone familiar WebExtensions clarify this a bit? Do we have some > policy here. Should we be as strict as with web APIs, or allow some > exceptions or do whatever people want/need? > > > > > -Olli > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
