Intent to ship: Gamepad API

2013-12-06 Thread Ted Mielczarek 
As of Firefox 28 I intend to turn the Gamepad API on by default (on
desktop Firefox). It has been developed behind the dom.gamepad.enabled 
preference, and shipped preffed-off in Firefox 24.

Google has shipped a prefixed but mostly-compatible implementation in
Chrome for multiple releases now. They're slightly less spec-compatible
than we are, and they're also not in line with a recent breaking spec
change that was made, but since they're still prefixed I don't think
that's a problem. The developer of the Google implementation is co-spec
editor along with me, so I don't forsee any issues with them fixing
their implementation.

I don't forsee any non-backwards-compatible changes being made to the
spec in the future, so I think this is a good time to ship and get more
exposure for the API.

Bug about enabling: https://bugzilla.mozilla.org/show_bug.cgi?id=878828
Gamepad API spec:
https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html (needs a
new WD published, that should happen in the near future)

-Ted

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NSPR logging dropping log messages

2013-12-06 Thread Honza Bambas 

On 12/6/2013 6:48 AM, Brian Smith wrote:

On Thu, Dec 5, 2013 at 9:46 PM, Robert O'Callahan  wrote:

bug 924253

I think we should also be careful that, when we have multiple
processes (which is always, because of e10s-based about:newtab
fetching), that those multiple processes are not clobbering each
other's output, when NSPR_LOG_FILE is used. I am not sure what the
current state of this is.

Cheers,
Brian
It's completely broken and I'm using the attached patch locally in any 
build I want to log to file for.

-hb-
# HG changeset patch
# Parent d263838ce6f98b15ba06f676fec5a0b31496f8f9
diff --git a/nsprpub/pr/src/io/prlog.c b/nsprpub/pr/src/io/prlog.c
--- a/nsprpub/pr/src/io/prlog.c
+++ b/nsprpub/pr/src/io/prlog.c
@@ -3,16 +3,17 @@
 /* This Source Code Form is subject to the terms of the Mozilla Public
  * License, v. 2.0. If a copy of the MPL was not distributed with this
  * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
 
 #include "primpl.h"
 #include "prenv.h"
 #include "prprf.h"
 #include 
+#include 
 #ifdef ANDROID
 #include 
 #endif
 
 /*
  * Lock used to lock the log.
  *
  * We can't define _PR_LOCK_LOG simply as PR_Lock because PR_Lock may
@@ -244,25 +245,27 @@ void _PR_InitLog(void)
 #ifdef XP_UNIX
 if ((getuid() != geteuid()) || (getgid() != getegid())) {
 return;
 }
 #endif /* XP_UNIX */
 
 ev = PR_GetEnv("NSPR_LOG_FILE");
 if (ev && ev[0]) {
-if (!PR_SetLogFile(ev)) {
+char buf[1024];
+PR_snprintf(buf, 1023, "%s.%d", ev, _getpid());
+if (!PR_SetLogFile(buf)) {
 #ifdef XP_PC
-char* str = PR_smprintf("Unable to create nspr log file 
'%s'\n", ev);
+char* str = PR_smprintf("Unable to create nspr log file 
'%s'\n", buf);
 if (str) {
 OutputDebugStringA(str);
 PR_smprintf_free(str);
 }
 #else
-fprintf(stderr, "Unable to create nspr log file '%s'\n", ev);
+fprintf(stderr, "Unable to create nspr log file '%s'\n", buf);
 #endif
 }
 } else {
 #ifdef _PR_USE_STDIO_FOR_LOGGING
 logFile = stderr;
 #else
 logFile = _pr_stderr;
 #endif
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NSPR logging dropping log messages

2013-12-06 Thread Ehsan Akhgari 

On 12/6/2013, 10:05 AM, Honza Bambas wrote:

On 12/6/2013 6:48 AM, Brian Smith wrote:

On Thu, Dec 5, 2013 at 9:46 PM, Robert O'Callahan
 wrote:

bug 924253

I think we should also be careful that, when we have multiple
processes (which is always, because of e10s-based about:newtab
fetching), that those multiple processes are not clobbering each
other's output, when NSPR_LOG_FILE is used. I am not sure what the
current state of this is.

Cheers,
Brian

It's completely broken and I'm using the attached patch locally in any
build I want to log to file for.


Can you please file a bug about this so that we can try to get this 
patch landed?  WTC recently indicated to me (in 
) that we 
should probably start adding support for having our own NSPR patches, so 
I would expect that with a bit of fiddling in the client.py code to 
update NSPR, we should be able to take this patch on top of the upstream 
NSPR in our tree.


Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Gamepad API

2013-12-06 Thread Ehsan Akhgari 

Thanks for posting this, Ted!

What is the dom.gamepad.non_standard_events.enabled controlling, and why 
do we have a different value of this pref in our release and non-release 
builds?


Thanks!
Ehsan

On 12/6/2013, 7:47 AM, Ted Mielczarek wrote:

As of Firefox 28 I intend to turn the Gamepad API on by default (on
desktop Firefox). It has been developed behind the dom.gamepad.enabled
preference, and shipped preffed-off in Firefox 24.

Google has shipped a prefixed but mostly-compatible implementation in
Chrome for multiple releases now. They're slightly less spec-compatible
than we are, and they're also not in line with a recent breaking spec
change that was made, but since they're still prefixed I don't think
that's a problem. The developer of the Google implementation is co-spec
editor along with me, so I don't forsee any issues with them fixing
their implementation.

I don't forsee any non-backwards-compatible changes being made to the
spec in the future, so I think this is a good time to ship and get more
exposure for the API.

Bug about enabling: https://bugzilla.mozilla.org/show_bug.cgi?id=878828
Gamepad API spec:
https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html (needs a
new WD published, that should happen in the near future)

-Ted

___
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: Intent to ship: Gamepad API

2013-12-06 Thread Ted Mielczarek 
On 12/6/2013 11:33 AM, Ehsan Akhgari wrote:
> Thanks for posting this, Ted!
>
> What is the dom.gamepad.non_standard_events.enabled controlling, and
> why do we have a different value of this pref in our release and
> non-release builds?
>

That pref controls whether we send "gamepadbutton{up,down}" and
"gamepadaxismove" events, which are not currently in the spec. I
implemented those in my original patch before a lot of discussion
happened which resulted in consensus that consumers wanted the
navigator.getGamepads() API more. I haven't had the energy to discuss
standardizing them (and we may not want to standardize exactly what I've
implemented, and Chrome doesn't implement them), so I left them in for
experimentation but disabled for release.

-Ted

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NSPR logging dropping log messages

2013-12-06 Thread Honza Bambas 

On 12/6/2013 5:31 PM, Ehsan Akhgari wrote:


Can you please file a bug about this so that we can try to get this 
patch landed?  WTC recently indicated to me (in 
) that we 
should probably start adding support for having our own NSPR patches, 
so I would expect that with a bit of fiddling in the client.py code to 
update NSPR, we should be able to take this patch on top of the 
upstream NSPR in our tree.


There is one, quite old: 
https://bugzilla.mozilla.org/show_bug.cgi?id=534764, many patches from 
many authors, one better then other ;))
Also be aware of https://bugzilla.mozilla.org/show_bug.cgi?id=801209 but 
there is absolutely no progress recently on that one.  IMO rather take 
small patches to NSPR then rewrite it all at the moment.


-hb-



Cheers,
Ehsan




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Gamepad API

2013-12-06 Thread Ehsan Akhgari 

On 12/6/2013, 11:43 AM, Ted Mielczarek wrote:

On 12/6/2013 11:33 AM, Ehsan Akhgari wrote:

Thanks for posting this, Ted!

What is the dom.gamepad.non_standard_events.enabled controlling, and
why do we have a different value of this pref in our release and
non-release builds?



That pref controls whether we send "gamepadbutton{up,down}" and
"gamepadaxismove" events, which are not currently in the spec. I
implemented those in my original patch before a lot of discussion
happened which resulted in consensus that consumers wanted the
navigator.getGamepads() API more. I haven't had the energy to discuss
standardizing them (and we may not want to standardize exactly what I've
implemented, and Chrome doesn't implement them), so I left them in for
experimentation but disabled for release.


Thanks, that makes sense.

Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NSPR logging dropping log messages

2013-12-06 Thread Ehsan Akhgari 

On 12/6/2013, 11:59 AM, Honza Bambas wrote:

On 12/6/2013 5:31 PM, Ehsan Akhgari wrote:


Can you please file a bug about this so that we can try to get this
patch landed?  WTC recently indicated to me (in
) that we
should probably start adding support for having our own NSPR patches,
so I would expect that with a bit of fiddling in the client.py code to
update NSPR, we should be able to take this patch on top of the
upstream NSPR in our tree.


There is one, quite old:
https://bugzilla.mozilla.org/show_bug.cgi?id=534764, many patches from
many authors, one better then other ;))
Also be aware of https://bugzilla.mozilla.org/show_bug.cgi?id=801209 but
there is absolutely no progress recently on that one.  IMO rather take
small patches to NSPR then rewrite it all at the moment.


I was talking about filing a bug where we would take the patch that you 
attached to the previous email.  I don't think any of those bugs that 
you referenced is the right place to do that.


Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NSPR logging dropping log messages

2013-12-06 Thread Honza Bambas 

On 12/6/2013 6:44 PM, Ehsan Akhgari wrote:
I was talking about filing a bug where we would take the patch that 
you attached to the previous email.  I don't think any of those bugs 
that you referenced is the right place to do that.


Cheers,
Ehsan


My patch is probably not something that should be on by default IMO.  It 
will create a new log file with .pid as an extension for every process 
we start, including the parent (main) process.  So it can well fill out 
your disk when you are not careful.  Also, you can easily get lost among 
all those files.  Hmm... mach run command could delete or (preferably) 
trash them, but still.


On the other hand, that patch is really a must for me personally.

-hb-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NSPR logging dropping log messages

2013-12-06 Thread Ehsan Akhgari 

On 12/6/2013, 1:19 PM, Honza Bambas wrote:

On 12/6/2013 6:44 PM, Ehsan Akhgari wrote:

I was talking about filing a bug where we would take the patch that
you attached to the previous email.  I don't think any of those bugs
that you referenced is the right place to do that.

Cheers,
Ehsan



My patch is probably not something that should be on by default IMO.  It
will create a new log file with .pid as an extension for every process
we start, including the parent (main) process.  So it can well fill out
your disk when you are not careful.  Also, you can easily get lost among
all those files.  Hmm... mach run command could delete or (preferably)
trash them, but still.

On the other hand, that patch is really a must for me personally.


What I was thinking about was that we would only create a log.pid file 
for anything that is not the main process.


Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NSPR logging dropping log messages

2013-12-06 Thread Honza Bambas 

On 12/6/2013 7:24 PM, Ehsan Akhgari wrote:

On 12/6/2013, 1:19 PM, Honza Bambas wrote:

On 12/6/2013 6:44 PM, Ehsan Akhgari wrote:

I was talking about filing a bug where we would take the patch that
you attached to the previous email.  I don't think any of those bugs
that you referenced is the right place to do that.

Cheers,
Ehsan



My patch is probably not something that should be on by default IMO.  It
will create a new log file with .pid as an extension for every process
we start, including the parent (main) process.  So it can well fill out
your disk when you are not careful.  Also, you can easily get lost among
all those files.  Hmm... mach run command could delete or (preferably)
trash them, but still.

On the other hand, that patch is really a must for me personally.


What I was thinking about was that we would only create a log.pid file 
for anything that is not the main process.


Ehsan


Something like 
https://bug534764.bugzilla.mozilla.org/attachment.cgi?id=481578 ? 
(Actually a platform bug)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NSPR logging dropping log messages

2013-12-06 Thread Ehsan Akhgari 

On 12/6/2013, 1:33 PM, Honza Bambas wrote:

On 12/6/2013 7:24 PM, Ehsan Akhgari wrote:

On 12/6/2013, 1:19 PM, Honza Bambas wrote:

On 12/6/2013 6:44 PM, Ehsan Akhgari wrote:

I was talking about filing a bug where we would take the patch that
you attached to the previous email.  I don't think any of those bugs
that you referenced is the right place to do that.

Cheers,
Ehsan



My patch is probably not something that should be on by default IMO.  It
will create a new log file with .pid as an extension for every process
we start, including the parent (main) process.  So it can well fill out
your disk when you are not careful.  Also, you can easily get lost among
all those files.  Hmm... mach run command could delete or (preferably)
trash them, but still.

On the other hand, that patch is really a must for me personally.


What I was thinking about was that we would only create a log.pid file
for anything that is not the main process.

Ehsan



Something like
https://bug534764.bugzilla.mozilla.org/attachment.cgi?id=481578 ?
(Actually a platform bug)


Sure!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Gamepad API

2013-12-06 Thread Ehsan Akhgari 

On 12/6/2013, 12:00 PM, Ehsan Akhgari wrote:

On 12/6/2013, 11:43 AM, Ted Mielczarek wrote:

On 12/6/2013 11:33 AM, Ehsan Akhgari wrote:

Thanks for posting this, Ted!

What is the dom.gamepad.non_standard_events.enabled controlling, and
why do we have a different value of this pref in our release and
non-release builds?



That pref controls whether we send "gamepadbutton{up,down}" and
"gamepadaxismove" events, which are not currently in the spec. I
implemented those in my original patch before a lot of discussion
happened which resulted in consensus that consumers wanted the
navigator.getGamepads() API more. I haven't had the energy to discuss
standardizing them (and we may not want to standardize exactly what I've
implemented, and Chrome doesn't implement them), so I left them in for
experimentation but disabled for release.


Thanks, that makes sense.


FWIW, I meant to say this "Looks Good To Me".  :-)

Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform