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, there
On 25/06/13 17:28, Robert O'Callahan wrote:
On Wed, Jun 26, 2013 at 4:15 AM, Mounir Lamouri mou...@lamouri.fr 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
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 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 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
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 about
On Wed, Jun 26, 2013 at 8:48 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
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
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)
On 2013-06-26 11:50 AM, Kyle Huey wrote:
On Wed, Jun 26, 2013 at 8:48 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
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
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 what
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 this
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 a list
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-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
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 the
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
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 ehsan.akhg...@gmail.comwrote:
On 2013-06-26 1:38 PM, Gavin Sharp wrote:
The message
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
On Wed, Jun 26, 2013 at 2:07 PM, Gavin Sharp ga...@gavinsharp.com 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
On Thu, Jun 27, 2013 at 3:59 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
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
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
21 matches
Mail list logo
