For B2G's gaia repository we are currently using xpcshell[1] as our
command line JS runner. I was noticing some horrible inconsistencies in
terms of blowing the JS stack when we were trying to use the esprima JS
parser[2] that varied by the platform and build type.
The nutshell is that the #d
On Thu, Jun 27, 2013 at 3:59 AM, Ehsan Akhgari wrote:
> On 2013-06-26 9:09 AM, Robert O'Callahan wrote:
>
>> If we think these use cases are (or ever will be) relevant, we need to
>> give
>> feedback even if we don't plan to implement them soon. We should at least
>> try to make sure these APIs ar
On Wed, Jun 26, 2013 at 2:07 PM, Gavin Sharp wrote:
> The scope of the current proposal is what's being debated; I don't think
> there's shared agreement that the scope should be "detectable from web
> script".
>
>
Partially embedded in this discussion is the notion that the open web
requires coo
Hi Marc,
I think this is good, and leads to more clarity than what we have today. I had
to squint a bit to get all the information out of the page below, so it may be
useful to be a bit more explicit as to what the things will look like in the
document itself. A few examples would help as wel
The scope of the current proposal is what's being debated; I don't think
there's shared agreement that the scope should be "detectable from web
script".
Gavin
On Wed, Jun 26, 2013 at 11:01 AM, Ehsan Akhgari wrote:
> On 2013-06-26 1:38 PM, Gavin Sharp wrote:
>
>> The message you quote has a spec
On 2013-06-26 1:38 PM, Gavin Sharp wrote:
The message you quote has a specific example - "Mozillians who have
experience designing JS APIs and will have at least one representative
from the JS team at all times" is probably not the best group to
determine whether we should implement support for/s
The message you quote has a specific example - "Mozillians who have
experience designing JS APIs and will have at least one representative
from the JS team at all times" is probably not the best group to
determine whether we should implement support for/ship SPDY, for
example. I think it's clear th
On 2013-06-25 9:02 PM, Jonas Sicking wrote:
"For new products, APIs that have not yet been embraced by other
vendors or thoroughly discussed by standards bodies may be shipped
only as a part of this product. Standardization must however start
within X months after shipping initial version of the
On 2013-06-26 12:08 PM, Andrew Overholt wrote:
"ship" is too restrictive. If a feature is implemented and available in
some version (even behind a flag) with a clear intent to ship it at some
point, this should be enough for us to follow.
I changed it to "at least two other browser engines ship
On 2013-06-26 12:28 PM, Brian Smith wrote:
I understand that Brendan would like to have more/all web-facing functionality covered by
some kind of guidelines similar to what you propose. I am not against that idea. However,
I don't think the rules you write work very well for the modules I work
On 2013-06-26 12:17 PM, Andrew Overholt wrote:
On 26/06/13 11:48 AM, Ehsan Akhgari wrote:
On 2013-06-26 11:21 AM, Andrew Overholt wrote:
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"?
Andrew Overholt wrote:
> On 25/06/13 10:11 AM, Brian Smith wrote:
> > In the document, instead of creating a blacklist of web technologies to
> > which the new policy would not apply (CSS, WebGL, WebRTC, etc.), please
> > list the modules to which the policy would apply.
>
> I started building up
On 26/06/13 11:48 AM, Ehsan Akhgari wrote:
On 2013-06-26 11:21 AM, Andrew Overholt wrote:
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ned to go through thi
On 25/06/13 12:15 PM, Mounir Lamouri wrote:
Note that at this time, we are specifically focusing on new JS APIs
and not on CSS, WebGL, WebRTC, or other existing features/properties.
I think the "JS APIs" here is unclear. I think saying "Web APIs" would
be more appropriate, assuming this is wh
On 2013-06-26 11:50 AM, Kyle Huey wrote:
On Wed, Jun 26, 2013 at 8:48 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote:
The other question is, what we're going to do about negative
feedback
from the API review phase but where the feedback cannot be
On 2013-06-26 9:09 AM, Robert O'Callahan wrote:
On Google's side, it is harder to find examples because I do not follow
that as closely but requestAutocomplete() is an example of an API that
Mozilla might not look at for quite some time.
If we think these use cases are (or ever will be) relev
On Wed, Jun 26, 2013 at 8:48 AM, Ehsan Akhgari wrote:
>
> The other question is, what we're going to do about negative feedback
>>> from the API review phase but where the feedback cannot be incorporated
>>> because of other concerns?
>>>
>>
>> I was thinking the module owner (or I guess the DOM m
On 2013-06-26 11:21 AM, Andrew Overholt wrote:
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ned to go through this process?
I was going to put a blurb abou
On 2013-06-26 11:11 AM, Andrew Overholt wrote:
5. "Once one week has passed [...]
This seems unnecessarily heavy-handed to me.
Agreed so I'll remove it. I'm actually thinking we still have the email
request but only to inform those who are interested in the feature
landing but haven't been fo
On 25/06/13 10:11 AM, Brian Smith wrote:
In the document, instead of creating a blacklist of web technologies to which
the new policy would not apply (CSS, WebGL, WebRTC, etc.), please list the
modules to which the policy would apply.
I started building up a list of modules to which the polic
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ned to go through this process?
I was going to put a blurb about "trivial changes" but thought it would
be too
On 24/06/13 01:50 PM, Kyle Huey wrote:
1. "at least one other browser vendor ships -- or publicly states their
intention to ship -- a compatible implementation of this API"
Because Apple and Microsoft generally do not publicly comment on
upcoming features, and Presto is no more, in practice this
On Thu, Jun 27, 2013 at 12:54 AM, Mounir Lamouri wrote:
> On 25/06/13 17:28, Robert O'Callahan wrote:
> > I don't see this. Can you give some examples?
>
> On Mozilla's side, there are a few APIs that we are pushing and do not
> interest other vendors for the moment. Most APIs related to Firefox
On 25/06/13 17:28, Robert O'Callahan wrote:
> On Wed, Jun 26, 2013 at 4:15 AM, Mounir Lamouri wrote:
>
>>> 3. APIs solving use cases which no browser vendor shipping an engine
>>> other Gecko is interested in at that time. In cases such as this,
>>> Mozilla will solicit feedback from as many rele
Hi Thomas,
MozICCManager is an API available only for built-in applications on
Firefox OS so it is fine to change it as much as you want.
--
Mounir
On 25/06/13 17:11, Thomas Zimmermann wrote:
> Hi,
>
> I intent to implement an extension to nsIDOMMozICCManager.
>
> When unlocking a SIM card, th
25 matches
Mail list logo
