On 12/12/2014 07:28 PM, Justin Dolske wrote:
However, I _do_ think it would be a good idea for the browser to
provide this functionality for all password fields OOTB. That provides
a consistent UX for a function we believe is valuable. I think
experience with autocomplete=off has shown that lot
On 12/12/14 2:59 PM, Andrew Sutherland wrote:
Is it reasonable to try and standardize support for an
"allow-show-password" boolean attribute and corresponding
allowShowPassword property on HTML inputs with type=password? There
would also be a showPassword property.
This seems overly complex.
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. Tha
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.
__
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 screen
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 s
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 shar
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 i
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
On 2014-12-12 6:16 PM, Jonas Sicking wrote:
On Fri, Dec 12, 2014 at 3:12 PM, Martin Thomson 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 this feature on b
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 is
On Fri, Dec 12, 2014 at 3:12 PM, Martin Thomson 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 this feature on by default.
Ooh, this is an interesting i
On Fri, Dec 12, 2014 at 2:59 PM, Andrew Sutherland
wrote:
> Is it reasonable to try and standardize support for an "allow-show-password"
> boolean attribute and corresponding allowShowPassword property on HTML
> inputs with type=password? There would also be a showPassword property.
> When allowS
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 ne
On 2014-12-12 5:54 PM, Jonas Sicking wrote:
On Fri, Dec 12, 2014 at 2:39 PM, Ehsan Akhgari 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 di
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 le
On Fri, Dec 12, 2014 at 2:39 PM, Ehsan Akhgari 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 test suite?
I
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 che
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 wrote:
> We had a session on intermittent test failures in Portland <
> https://etherpad.mozilla.org/ateam-pdx-intermittent-oranges>, and one of
> the th
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 <
https://developer.mozilla.org/en-US/docs/Mozilla/Q
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 w
On Thu, Dec 11, 2014 at 3:48 PM, Jonas Sicking wrote:
> On Thu, Dec 11, 2014 at 11:17 AM, Alex Russell
> 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 scenarios discussed
> in this thread,
On Thu, Dec 11, 2014 at 11:04 AM, Ehsan Akhgari
wrote:
> On 2014-12-11 2:03 AM, Jonas Sicking wrote:
>
>> On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell
>> wrote:
>>
>>> On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari
>>> wrote:
>>>
On 2014-12-10 7:45 PM, Jonas Sicking wrote:
>
\o/
On Thu, Dec 11, 2014 at 5:15 PM, Jonas Sicking wrote:
> Yes!
>
> On Thu, Dec 11, 2014 at 5:11 PM, Kyle Machulis
> wrote:
> > Summary: We've already got the performance resource timing API
> implemented (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but
> never got around to implemen
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 compu
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
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/EventL
26 matches
Mail list logo
