Re: Extensions and Gecko specific APIs

[mconca]

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

[Andrew Swan]

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 Fink  wrote:

> 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

[Bill McCloskey]

On Thu, Jul 27, 2017 at 7:14 PM, Nicholas Nethercote  wrote:

> 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

[Nicholas Nethercote]

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

[Steve Fink]

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

[Enrico Weigelt, metux IT consult]

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

[Enrico Weigelt, metux IT consult]

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

[Andrew Swan]

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

[Steve Wendt]

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

[Steve Fink]

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

[Karl Dubost]

David, others,

Le 26 juil. 2017 à 17:58, David Teller  a é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

[Mike Taylor]

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

[Ehsan Akhgari]

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 Overholt  wrote:

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

[David Teller]

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 Overholt  wrote:
>> 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

[Martin Thomson]

On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholt  wrote:
> 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

[Robert O'Callahan]

Experience from Web content standards probably informs the situation here...

On Wed, Jul 26, 2017 at 11:46 AM, Andrew Swan  wrote:

> 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

[Robert O'Callahan]

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

[Andrew Swan]

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

Re: Extensions and Gecko specific APIs

[gsquelart]

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 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?
> 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

[Andrew Overholt]

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?
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

[David Teller]

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

[Jet Villegas]

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

Re: Extensions and Gecko specific APIs

[Gabor Krizsanits]

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, 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

Extensions and Gecko specific APIs

[smaug]

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