Re: Extensions and Gecko specific APIs
On Monday, July 31, 2017 at 11:09:03 PM UTC-6, Andrew Swan wrote: > For further discussion about the longer term strategy, I would suggest > following up with Kev Needham who oversees all of addons. Also, Mike Conca > just started as the product manager for WebExtensions. But to be fair to > him, he's now in his second full week here and if his experience is > anything like mine was, he's still just trying not to get knocked down by > the Mozilla-newcomer-firehose. As of day seven the Mozilla-newcomer-firehose is, unfortunately, still knocking me down on a regular basis. Nevertheless, in my short time here, it's been mentioned to me a few times that there is a need for a more structured, visible process by which potential extensions are captured as ideas, reviewed by relevant stakeholders, and eventually delivered to the world. I hope to make this a primary area of focus over the next several months. -Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
Sorry for the slow reply, I was half-waiting to see if anybody else would jump in but I guess product managers don't follow dev-platform :) I think we're mostly in sync on most of the nuts and bolts and the unresolved topics are generally pretty high-level concerns. On Thu, Jul 27, 2017 at 10:02 AM, Steve Finkwrote: > 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). > > > And I guess the parenthetical clause is what worries me. The people > churning through that workload should be churning through that workload, > and it's fine that they aren't spending time and mental space on the > theoretical concerns of future compatibility issues or addon developer > relations. But this is kind of a big deal for Mozilla strategically, so I > would expect someone else to be working on the strategic plan before we > reach the foot-shooting point. > > Hopefully, that someone would be in close contact with the engineers doing > the work, since they have the best context and familiarity with large parts > of the problem space, and hence their opinions deserve a lot of weight. As > long as the consultation doesn't get in the way of getting stuff done. > There's a ton of weight on you people's shoulders, and we don't want to add > more. > > One person can do both strategy and tactics (or implementation) just fine, > but it's usually not a good idea to do them at the same time. Different > mindset, different tradeoffs. > 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). > > > Yeah, that's not really what I'm talking about. In a way, that's the hard > part. But it's unavoidable, and it's happening in practice, and I'm sure > there'll be a lag in formalization while things are taking shape. That's > probably a good thing, since it'll require experience to flesh these things > out. > > But that's about individual APIs. I want high-level answers to the > simultaneous questions "How are we going to expose sufficient functionality > to provide extension authors with what they need?" and "How are we going to > avoid shooting ourselves in the foot when we get further down the road?" > The sort of things you read in high-level strategy documents that set down > the goals, direction, and approach to known obstacles. (Not that I > necessarily want such a document; they're boring and make for dull reading, > and I'm always suspicious as to whether anyone's paying attention to them. > But I want the thinking behind it.) > I think the basic principles here are pretty simple and I tried to lay them out before. We're drawing a line and saying that we'll only expose things to WebExtensions that can be done in a way that is safe for users and maintainable for us (ie the people that work on gecko/firefox). Within those boundaries, we're willing to provide whatever extension authors need. Exactly how the terms "safe for users" and "maintainable for us" are defined is mostly an engineering decision (and occasionally a product or UX decision) and to be frank, we're still nailing down exactly how strict we should be (for what its worth I think we've personally been relatively conservative thus far). Anyway, I think the real strategy questions are about how much we will invest in building these APIs ourselves -- every engineer who is working on extension APIs is an engineer who is not working on performance or other new features. A related question is who exactly should be creating extension APIs. We have a dedicated team right now in the midst of a big blitz to bootstrap (no pun intended) the whole WebExtensions platform but in the longer term I think it makes a lot more sense for engineers who know individual areas of the code well to be the ones creating extension APIs that touch those areas. On the other hand, that's adding to everybody's already overfull workloads. This is a fine problem for engineering management to wrestle with while the rest of us keep busy writing code :) For further discussion about the longer term strategy, I would suggest following up with Kev Needham who oversees all of addons. Also, Mike Conca just started as the product manager for WebExtensions. But to be fair to him, he's now in his second full week here and if his experience is anything like mine was, he's still just trying not to get knocked down by the Mozilla-newcomer-firehose. -Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
On Thu, Jul 27, 2017 at 7:14 PM, Nicholas Nethercotewrote: > FWIW, I share Steve's broad concerns here. Mozilla's track record on > extension APIs has had many dead-ends and changes of direction. Now that > we're wiping the slate clean, it would be good to not repeat history. > I'm surprised it hasn't been mentioned here, but there is a process in place for new APIs. This is my understanding of how it works: 1. API is prototyped as a WebExtension experiment. There's a fair amount of documentation on how to do this [1], including API guidelines [2]. This would be a probably good place for people to add rules of thumb, like roc's point about free-form JSON being a bad idea. 2. File a bug for the API and mark it [design-decision-needed]. The API will be discussed first in the bug, then in the community meeting, and possibly brought to the WebExtensions advisory group [3] if there are any concerns. 3. The API will be either accepted or rejected. Quite a few do get rejected, so it's not a rubber stamp. I think it's common for step 1 to be omitted, in which case someone from the WebExtension team has to implement the API. But the intention is to allow add-on developers to be able to propose an API without having to wait for us to implement it. If people have concerns, the best thing to do is to be a part of this process. It's an open discussion, and I think that it would benefit from more platform people participating--especially people who have experience with web standards. There also has been a lot of discussion of this process itself on dev-addons, which is where most of this stuff gets talked about. -Bill [1] https://webextensions-experiments.readthedocs.io/en/latest/ [2] https://webextensions-experiments.readthedocs.io/en/latest/new.html [3] https://wiki.mozilla.org/WebExtensions/AdvisoryGroup > Nick > > On Fri, Jul 28, 2017 at 3:02 AM, Steve Fink wrote: > > > On 07/26/2017 10:45 PM, Andrew Swan wrote: > > > >> > >> 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. > >> > > > > "this" == exposing Gecko-specific functionality, or rather, what > > Gecko-specific functionality to expose and how to expose it in general. > > With emphasis on the how. The prefixing decision (answer: no) and > > do-it-at-all decision (answer: yes) are part of that. > > > > 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). > >> > > > > And I guess the parenthetical clause is what worries me. The people > > churning through that workload should be churning through that workload, > > and it's fine that they aren't spending time and mental space on the > > theoretical concerns of future compatibility issues or addon developer > > relations. But this is kind of a big deal for Mozilla strategically, so I > > would expect someone else to be working on the strategic plan before we > > reach the foot-shooting point. > > > > Hopefully, that someone would be in close contact with the engineers > doing > > the work, since they have the best context and familiarity with large > parts > > of the problem space, and hence their opinions deserve a lot of weight. > As > > long as the consultation doesn't get in the way of getting stuff done. > > There's a ton of weight on you people's shoulders, and we don't want to > add > > more. > > > > One person can do both strategy and tactics (or implementation) just > fine, > > but it's usually not a good idea to do them at the same time. Different > > mindset, different tradeoffs. > > > > > >> 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. > >> > > >
Re: Extensions and Gecko specific APIs
FWIW, I share Steve's broad concerns here. Mozilla's track record on extension APIs has had many dead-ends and changes of direction. Now that we're wiping the slate clean, it would be good to not repeat history. Nick On Fri, Jul 28, 2017 at 3:02 AM, Steve Finkwrote: > On 07/26/2017 10:45 PM, Andrew Swan wrote: > >> >> 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. >> > > "this" == exposing Gecko-specific functionality, or rather, what > Gecko-specific functionality to expose and how to expose it in general. > With emphasis on the how. The prefixing decision (answer: no) and > do-it-at-all decision (answer: yes) are part of that. > > 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). >> > > And I guess the parenthetical clause is what worries me. The people > churning through that workload should be churning through that workload, > and it's fine that they aren't spending time and mental space on the > theoretical concerns of future compatibility issues or addon developer > relations. But this is kind of a big deal for Mozilla strategically, so I > would expect someone else to be working on the strategic plan before we > reach the foot-shooting point. > > Hopefully, that someone would be in close contact with the engineers doing > the work, since they have the best context and familiarity with large parts > of the problem space, and hence their opinions deserve a lot of weight. As > long as the consultation doesn't get in the way of getting stuff done. > There's a ton of weight on you people's shoulders, and we don't want to add > more. > > One person can do both strategy and tactics (or implementation) just fine, > but it's usually not a good idea to do them at the same time. Different > mindset, different tradeoffs. > > >> 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. >> > > I agree. But it isn't completely different from webcompat, either. We have > used up much of developer's tolerance for breaking changes, so we really > want to try hard to minimize changes that are going to break addons. (And > minimize the pain of such breakage -- if we have a mechanism allowing us to > easily identify the addons that will be affected, and provide a warning and > documentation of the change in advance, we can probably get away with quite > a bit.) > > 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. >> > > Sure, and in my mind, that's the sort of tactical decisionmaking that > *should* be done in the context of implementation. Which is different from > the overall strategy of prefixing / opt-in imports / signing / versioning. > > 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. >> > > Sorry, don't take my ranting to imply that I'm somehow unhappy with the > work you people are doing. To the contrary, it all seems to be going > stunningly well, which is much to the credit of your team. > > >> That's my argument for why the default
Re: Extensions and Gecko specific APIs
On 07/26/2017 10:45 PM, Andrew Swan wrote: On Wed, Jul 26, 2017 at 4:27 PM, Steve Fink> 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. "this" == exposing Gecko-specific functionality, or rather, what Gecko-specific functionality to expose and how to expose it in general. With emphasis on the how. The prefixing decision (answer: no) and do-it-at-all decision (answer: yes) are part of that. 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). And I guess the parenthetical clause is what worries me. The people churning through that workload should be churning through that workload, and it's fine that they aren't spending time and mental space on the theoretical concerns of future compatibility issues or addon developer relations. But this is kind of a big deal for Mozilla strategically, so I would expect someone else to be working on the strategic plan before we reach the foot-shooting point. Hopefully, that someone would be in close contact with the engineers doing the work, since they have the best context and familiarity with large parts of the problem space, and hence their opinions deserve a lot of weight. As long as the consultation doesn't get in the way of getting stuff done. There's a ton of weight on you people's shoulders, and we don't want to add more. One person can do both strategy and tactics (or implementation) just fine, but it's usually not a good idea to do them at the same time. Different mindset, different tradeoffs. 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. I agree. But it isn't completely different from webcompat, either. We have used up much of developer's tolerance for breaking changes, so we really want to try hard to minimize changes that are going to break addons. (And minimize the pain of such breakage -- if we have a mechanism allowing us to easily identify the addons that will be affected, and provide a warning and documentation of the change in advance, we can probably get away with quite a bit.) 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. Sure, and in my mind, that's the sort of tactical decisionmaking that *should* be done in the context of implementation. Which is different from the overall strategy of prefixing / opt-in imports / signing / versioning. 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. Sorry, don't take my ranting to imply that I'm somehow unhappy with the work you people are doing. To the contrary, it all seems to be going stunningly well, which is much to the credit of your team. 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
Re: Extensions and Gecko specific APIs
On 26.07.2017 23:27, Steve Fink wrote: Doing this at a time of weak market share is... courageous[2]. Remember when the whole FOSS movement started - the market share was about zero. In short: better to have fewer users now with a high quality product ACK. Leave the toys to others. But to make the sacrifice worthwhile, that means we have to *be* a high quality product. ACK. And to achieve that, there's a lot to clean up. 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 For example small footprint and easily managable code. --mtx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
On 26.07.2017 22:23, Karl Dubost wrote: As soon as some people are willing to adopt one of the browser > "lab-style-features" in the open, because well it solves their > issues and plays well with the ecosystem market shares, the the vendor prefix strategy is falling apart for everyone else. > It makes even things worse on a long term. Maybe it's less painful when these things have to be explicitly enabled by the user. So, arbitrary web coders (hopefully) don't get the idea of relying on them. And they should have a limited lifetime. --mtx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
On Wed, Jul 26, 2017 at 4:27 PM, Steve Finkwrote: > 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
Re: Extensions and Gecko specific APIs
On 7/26/2017 4:27 PM, Steve Fink wrote: it's a bold move that says we're willing to take the painful hit of pissing off addon authors and users That has certainly happened... But to make the sacrifice worthwhile, that means we have to *be* a high quality product. One with a competitive edge. Which means that people have a reason to choose us over the alternatives. And while we can and should look for other ways of doing that, via activity streams or privacy or Accounts or better tab handling, our historical edge has been extensibility and customizability. Firefox is sticky because people can make it do what they want, things that they come to depend on enough that they feel like they're missing out by switching browsers. (Even if people don't *actually* make use of it, knowing that the capability is there is powerful.) Indeed. Many of the changes the last few years have left a lot of users asking "if they are just copying Chrome, why shouldn't we switch to that?" I think "extensibility and customizability" is what kept many people from doing so, and now some of that is going away... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
This thread worries me greatly. Somebody tell me we have a plan and policy around this already. Please? We're taking the regrettable but necessary step of killing off legacy style extension "APIs"[1]. Necessary because e10s and the basic impossibility of maintaining security, stability, performance, etc. with a wide-open extension mechanism. Doing this at a time of weak market share is... courageous[2]. 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. In short: better to have fewer users now with a high quality product that has the ability to grow, than to retain more users on a lower-quality product. But to make the sacrifice worthwhile, that means we have to *be* a high quality product. One with a competitive edge. Which means that people have a reason to choose us over the alternatives. And while we can and should look for other ways of doing that, via activity streams or privacy or Accounts or better tab handling, our historical edge has been extensibility and customizability. Firefox is sticky because people can make it do what they want, things that they come to depend on enough that they feel like they're missing out by switching browsers. (Even if people don't *actually* make use of it, knowing that the capability is there is powerful.) 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. The thing tempering this answer, of course, is that we don't want to paint ourselves into another corner[3]. The extension API is on its own standardization treadmill, and extension APIs that change or differ from what ends up getting standardized could be a problem. So I would hope that we've given this some serious thought and come up with a plan and policy for how to do it. I have ideas[4], but I certainly hope other people have given this a lot more thought already. 1. Calling the previous extension mechanism an API is giving it too much credit. "Stuff we didn't prevent from being used, that was useful for making addons"? 2. I would call it crazy and stupid move if I didn't happen to agree with it. Or if I was ok with calling myself crazy and stupid. And I'm not crazy. 3. Uh... I've never really thought about it before, but who paints their floors? I wouldn't think that'd wear well. I guess "Let's not Wet Swiffer ourselves into a corner!" doesn't have quite the same ring. 4. This scenario is easier than general web compatibility, because (1) we have an upgrade mechanism for addons, and (2) we're starting out so have the opportunity to set things up to make changes easier. For example, if you had to explicitly import specific extension points, it would be much easier to know what is being used and what might break; no need to bend over backwards to do feature detection. Also, some of the arguments against versioning JS or DOM don't apply here, so we might consider that in some form. We even have a signing mechanism, so we could control access on a per-API basis if it would help. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
David, others, Le 26 juil. 2017 à 17:58, David Tellera écrit : > moz-prefixing makes it clear that the feature can be absent on some > browsers. vendor prefixes were of a good intent, an idea of a safe space to explore a technology without breaking stuff in the real world (aka pharmaceutical lab) but it didn't work. Probably because pharmaceutical labs are closed worlds (because patents, economic interests, policies aka social structures). Browsers live in an open world were we expose what we do. This changes a lot of things. One of them is market forces. Vendor prefixes would be less terrible if all browsers had equal market shares (read here "unintentional power to modify the ecosystem" just to assume the best in everyone). As soon as some people are willing to adopt one of the browser "lab-style-features" in the open, because well it solves their issues and plays well with the ecosystem market shares, the vendor prefix strategy is falling apart for everyone else. It makes even things worse on a long term. Be open as much as possible. Draft specifications for things you think are interesting for the world. If something is really good for Gecko, it might be good for others. Don't compete on the uniqueness of your features, but on the excellency of your features. (just some thoughts from a 6+ years, and counting, webcompat frontline) -- Karl Dubost, mozilla Webcompat http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
On 7/26/17 3:06 PM, Ehsan Akhgari wrote: > On 07/26/2017 04:58 AM, David Teller wrote: >> Well, at least there is the matter of feature detection, for people who >> want to write code that will work in more than just Firefox. >> moz-prefixing makes it clear that the feature can be absent on some >> browsers. > Until the day that said other browser gets forced into implementing > those prefixed names due to reasons such as mass adoption of the > prefixed names by developers. Here is a practical example from recent > history: > https://searchfox.org/mozilla-central/rev/8a61c71153a79cda2e1ae7d477564347c607cc5f/dom/webidl/HTMLInputElement.webidl#224 Yes, let's avoid repeating vendor-prefix history. It didn't end well last time. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
On 07/26/2017 04:58 AM, David Teller wrote: Well, at least there is the matter of feature detection, for people who want to write code that will work in more than just Firefox. moz-prefixing makes it clear that the feature can be absent on some browsers. Until the day that said other browser gets forced into implementing those prefixed names due to reasons such as mass adoption of the prefixed names by developers. Here is a practical example from recent history: https://searchfox.org/mozilla-central/rev/8a61c71153a79cda2e1ae7d477564347c607cc5f/dom/webidl/HTMLInputElement.webidl#224 Cheers, David On 26/07/17 05:55, Martin Thomson wrote: On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholtwrote: On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: Should we moz-prefix moz-specific extensions? We have been trying not to do that for Web-exposed APIs but maybe the extensions case is different? I don't think that it is. If there is any risk at all that someone else might want to use it, then prefixing will only make our life harder long term. Good names are cheap enough that we don't need to wall ours off. See also https://tools.ietf.org/html/rfc6648 ___ 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
Re: Extensions and Gecko specific APIs
Well, at least there is the matter of feature detection, for people who want to write code that will work in more than just Firefox. moz-prefixing makes it clear that the feature can be absent on some browsers. Cheers, David On 26/07/17 05:55, Martin Thomson wrote: > On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholtwrote: >> On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: >>> Should we moz-prefix moz-specific extensions? >> >> We have been trying not to do that for Web-exposed APIs but maybe the >> extensions case is different? > > I don't think that it is. If there is any risk at all that someone > else might want to use it, then prefixing will only make our life > harder long term. Good names are cheap enough that we don't need to > wall ours off. > > See also https://tools.ietf.org/html/rfc6648 > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholtwrote: > On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: >> Should we moz-prefix moz-specific extensions? > > We have been trying not to do that for Web-exposed APIs but maybe the > extensions case is different? I don't think that it is. If there is any risk at all that someone else might want to use it, then prefixing will only make our life harder long term. Good names are cheap enough that we don't need to wall ours off. See also https://tools.ietf.org/html/rfc6648 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
Experience from Web content standards probably informs the situation here... On Wed, Jul 26, 2017 at 11:46 AM, Andrew Swanwrote: > 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. You probably don't want to use a prefix there. What if some other browser decided to support containers? Then they'd want to implement your API and having it be prefixed is then horrible for everyone. 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? > It's probably best to be pessimistic about extension developers' behaviour. In practice the tabs API, or any other API, is either universally present in the browsers they care about, or it is not. In the former case they will rely on it explicitly or implicitly (e.g. by having untested fallback code paths that don't work). In the latter case they will discover the problem and fix it. Either way naming probably doesn't help much. Developers of your putative non-tabbed browser would have to recognize the situation and decide what's best for them. If there are lots of extensions that rely on the tabs API, maybe the browser developers would have to put in some stub implementation that tries to do something sensible. One thing that might help (and maybe you already have this?) is to have the extension manifest contain a whitelist of the set of APIs the extension requires. That would allow easy filtering to determine which extensions are supported by a browser. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
On Wed, Jul 26, 2017 at 11:07 AM,wrote: > I think that such an API could be spec'd such that it is portable, with > the output being flexible enough that we can put Mozilla-specific > information in there. E.g.: A fixed API to get the data, and a minimal > structure for the output, but say, each log message could have a free-form > 'data' json object, or some self-described tabular data. > The latter approach has generally turned out to be a mistake. Often, all it achieves is to shift compatibility problems to a different level, where the problems may not be recognized, or there may be no standards process to deal with them, or the usual methods for feature detection do not work. If you want to have Mozilla-specific extensions, be honest about it and just add them to the WebExtensions API. One option here might be to have an API that returns strings of human-readable text, although that's dangerous too because people might try to parse it. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
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, smaugwrote: > 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
Re: Extensions and Gecko specific APIs
On Wednesday, July 26, 2017 at 8:21:23 AM UTC+12, Andrew Overholt wrote: > On Tue, Jul 25, 2017 at 3:06 PM, David Tellerwrote: > > > Should we moz-prefix moz-specific extensions? > > > We have been trying not to do that for Web-exposed APIs but maybe the > extensions case is different? > https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guiding_Principles Thank you Olli for starting this discussion. For some context: Olli reviewed my initial attempt to bring some [chrome-only] moz-specific extensions for use in the legacy about:media extension, to a privilege-gated API for use in a (Web)Extension rewrite, to make it work at least as well as the old one. So in my case, I'd like to get some debugging data from a element, and build a useful DevTools panel from that. (Currently we have APIs like HTMLMediaElement.mozRequestDebugInfo() to get such data, but only extensions with the "debugger" or "tabs" privilege can see them; so any random webdev won't see these things.) The collected data will be a kind of log that captures the changing state of our Media Playback stack and how data goes through it; a bit similar to what an unnamed competitor already does in their 'chrome://media-internals/' page -- but much better of course! I think that such an API could be spec'd such that it is portable, with the output being flexible enough that we can put Mozilla-specific information in there. E.g.: A fixed API to get the data, and a minimal structure for the output, but say, each log message could have a free-form 'data' json object, or some self-described tabular data. But with no experience in producing cross-browser specs, I'm scared that such a process would be time-consuming(?) So in the interest of producing a useful Media DevTools Panel soon-ish I'm thinking of continuing with moz-specific APIs for now, as development progresses and I tweak these APIs... But with the view of eventually converting them to a proper WebExtension API. Of course the risk there is that once we have a working DevTools panel, there may be little incentive to Do The Right Thing and work on proper specs. What do you all think? (in general and/or for my specific case) Thanks, Gerald ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
On Tue, Jul 25, 2017 at 3:06 PM, David Tellerwrote: > Should we moz-prefix moz-specific extensions? We have been trying not to do that for Web-exposed APIs but maybe the extensions case is different? https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guiding_Principles ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
Should we moz-prefix moz-specific extensions? On 25/07/17 20:45, Jet Villegas wrote: > Based on product plans I've heard, this sounds like the right approach. We > should try to limit the scope of such browser-specific APIs but it's likely > necessary in some cases (e.g., in the devtools.) > > > On Tue, Jul 25, 2017 at 2:44 AM, Gabor Krizsanits> wrote: > >> In my mind at least the concept is to share the API across all browsers >> where we can, but WebExtensions should not be limited to APIs that are >> accepted and implemented by all browser vendors. >> > ___ > 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
Re: Extensions and Gecko specific APIs
Based on product plans I've heard, this sounds like the right approach. We should try to limit the scope of such browser-specific APIs but it's likely necessary in some cases (e.g., in the devtools.) On Tue, Jul 25, 2017 at 2:44 AM, Gabor Krizsanitswrote: > In my mind at least the concept is to share the API across all browsers > where we can, but WebExtensions should not be limited to APIs that are > accepted and implemented by all browser vendors. > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
In my mind at least the concept is to share the API across all browsers where we can, but WebExtensions should not be limited to APIs that are accepted and implemented by all browser vendors. Google extensions have some Google app specific API that we might never implement because of technical limitations, and we certainly plan to add APIs that Google will never implement because of policy reasons for example. I hope one day we can even have decent specs around some of the common API ( https://browserext.github.io/), and for new APIs I guess we should try to work together with other vendors as much as possible IF that makes sense. But if it's about an API that is needed for a popular Firefox specific extension to be ported, and it's totally out of policy for Google extensions anyway, then we should "only" care about security and the extra cost it might cause for US to keep supporting it. And since we're trying to move away from manual review http://www.agmweb.ca/2017-07-11-manual-review/ we should probably be quite conservative about what we accept. Gabor On Tue, Jul 25, 2017 at 11:14 AM, smaugwrote: > 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