Analyzing Asynchronous Callbacks

2014-12-12 Thread Erdal Mutlu
Hi all, I am currently working on races that can happen across asynchronous event callbacks. I started investigating the Mozilla source code hoping that I can find a concrete event loop and queue implementation as discussed in

Re: after NPAPI ?

2014-12-12 Thread raynaudp
Hi, sorry for the late answer. It's audio speaking, so it's not 10 but 20 ms the max. But HTML5 can't provide it. The problem using Geko is that geko take 10-40 ms,windows take 15 ms, ... and at the end, I've more than 50ms ... Perhaps using another way : How could I start program on a

Re: Intent to Implement: User Timing API

2014-12-12 Thread Ilya Grigorik
\o/ On Thu, Dec 11, 2014 at 5:15 PM, Jonas Sicking jo...@sicking.cc wrote: Yes! On Thu, Dec 11, 2014 at 5:11 PM, Kyle Machulis kmachu...@mozilla.com wrote: Summary: We've already got the performance resource timing API implemented (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but

Re: Cross origin communication and the navigator.connect API

2014-12-12 Thread Alex Russell
On Thu, Dec 11, 2014 at 11:04 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-12-11 2:03 AM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell slightly...@google.com wrote: On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On

Re: Cross origin communication and the navigator.connect API

2014-12-12 Thread Alex Russell
On Thu, Dec 11, 2014 at 3:48 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Dec 11, 2014 at 11:17 AM, Alex Russell slightly...@google.com wrote: For the purposes of API composition, either this (or navigator.connect()) will do. One thing that we'll need to solve in a lot of the

It is time to solve making a push to Try server show a performance regression or validate a fix

2014-12-12 Thread jmaher
In the history of running Talos, there has never been an easy way to determine if your change has fixed a regression or created a new one. We have compare.py and compare-talos which are actually quite useful, but it requires you to run yet another tool - in short you have to break your normal

PSA: Flaky timeouts in mochitest-plain now fail newly added tests

2014-12-12 Thread Ehsan Akhgari
We had a session on intermittent test failures in Portland https://etherpad.mozilla.org/ateam-pdx-intermittent-oranges, and one of the things that we discussed was adding analyses to our test suites that detect known bad test writing practices

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

2014-12-12 Thread Jonas Sicking
Awesome! I think this would be great to have for the integration tests in B2G as well. / Jonas On Fri, Dec 12, 2014 at 10:34 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: We had a session on intermittent test failures in Portland https://etherpad.mozilla.org/ateam-pdx-intermittent-oranges,

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

2014-12-12 Thread Ehsan Akhgari
On 2014-12-12 5:33 PM, Jonas Sicking wrote: Awesome! I think this would be great to have for the integration tests in B2G as well. It is already live for all mochitest-plains run on b2g, or did you mean another test suite? If the latter, I'd be happy to file bugs and help folks adopt the

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

2014-12-12 Thread Jonas Sicking
On Fri, Dec 12, 2014 at 2:39 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-12-12 5:33 PM, Jonas Sicking wrote: Awesome! I think this would be great to have for the integration tests in B2G as well. It is already live for all mochitest-plains run on b2g, or did you mean another

Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Andrew Sutherland
One of the UI polish issues that is facing Firefox OS apps is inclusion of a show password mechanism. Although the adoption of Web Components makes this something that can be addressed in a somewhat unified fashion, this seems like an affordance that is probably universally desired on (at

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

2014-12-12 Thread Ehsan Akhgari
On 2014-12-12 5:54 PM, Jonas Sicking wrote: On Fri, Dec 12, 2014 at 2:39 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-12-12 5:33 PM, Jonas Sicking wrote: Awesome! I think this would be great to have for the integration tests in B2G as well. It is already live for all

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Martin Thomson
Why not simply provide a way to show the password always? I believe that Microsoft always provides the little eye icon in their new password input fields. If anything, I'd have this feature on by default. If you are pwned to the extent that an attacker is scraping pixels, I don't think we

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Tanvi Vyas
A touch event or mouseclick-and-hold on the eye icon could show the password, and as soon as the user releases the password can go back to being obfuscated. That would prevent accidental leakage through screen sharing. The tricky part is adding such an icon next to the password field (same

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Ehsan Akhgari
On 2014-12-12 6:16 PM, Jonas Sicking wrote: On Fri, Dec 12, 2014 at 3:12 PM, Martin Thomson m...@mozilla.com wrote: Why not simply provide a way to show the password always? I believe that Microsoft always provides the little eye icon in their new password input fields. If anything, I'd have

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Martin Thomson
On 12/12/14 15:19, Tanvi Vyas wrote: A touch event or mouseclick-and-hold on the eye icon could show the password, and as soon as the user releases the password can go back to being obfuscated. That would prevent accidental leakage through screen sharing. The tricky part is adding such an icon

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Ehsan Akhgari
On 2014-12-12 6:19 PM, Tanvi Vyas wrote: A touch event or mouseclick-and-hold on the eye icon could show the password, and as soon as the user releases the password can go back to being obfuscated. That would prevent accidental leakage through screen sharing. The tricky part is adding such an

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Mike Habicher
On 14-12-12 06:19 PM, Tanvi Vyas wrote: A touch event or mouseclick-and-hold on the eye icon could show the password, and as soon as the user releases the password can go back to being obfuscated.  That would prevent accidental leakage through screen

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Ehsan Akhgari
On 2014-12-12 6:27 PM, Mike Habicher wrote: On 14-12-12 06:19 PM, Tanvi Vyas wrote: A touch event or mouseclick-and-hold on the eye icon could show the password, and as soon as the user releases the password can go back to being obfuscated. That would prevent accidental leakage through screen

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Andrew Sutherland
On 12/12/2014 06:24 PM, Ehsan Akhgari wrote: On 2014-12-12 6:19 PM, Tanvi Vyas wrote: A touch event or mouseclick-and-hold on the eye icon could show the password, and as soon as the user releases the password can go back to being obfuscated. That would prevent accidental leakage through

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Martin Thomson
On 12/12/14 15:29, Ehsan Akhgari wrote: FWIW screen sharing has a ton of other unsolved privacy issues as well. Yes, I would put this in the wholly manageable category of issues. I think that a straight toggle (rather than click/touch and hold) is fine for this.

Re: Sane/possible to implement/standardize opt-in (user and page) mobile show password behavior for HTML input type=password?

2014-12-12 Thread Ehsan Akhgari
On 2014-12-12 6:34 PM, Andrew Sutherland wrote: On 12/12/2014 06:24 PM, Ehsan Akhgari wrote: On 2014-12-12 6:19 PM, Tanvi Vyas wrote: A touch event or mouseclick-and-hold on the eye icon could show the password, and as soon as the user releases the password can go back to being obfuscated.