The default bug view has changed. See this FAQ.

[Mac] password entry fields not identified as such, entering password does not generate typical audible click

RESOLVED FIXED in mozilla14

Status

()

Core
Disability Access APIs
P1
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: MarcoZ, Assigned: hub)

Tracking

(Blocks: 1 bug)

Trunk
mozilla14
x86_64
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Password entry fields have the following problems:
1. Their role description is not properly identified.
2. When entering text, the typical password click that can be heard in Safari and elsewhere within Mac OS X is not being generated.

I'm marking this bug security sensitive for now because I do not know if this can be exploited to somehow gain access to a user-entered password.
(Reporter)

Updated

5 years ago
Priority: -- → P1
I don't think this is a security bug that needs to be hidden. The lack of sound might fool a user into not knowing it's a password field? But if so they wouldn't be entering their password. The lack of sound means they're lost and don't know which fields are which, resorting to guessing? Yeah, that's a problem, but if it's causing that kind of confusion people will know that even if they can't see this bug.
Group: core-security
(Assignee)

Updated

5 years ago
Assignee: nobody → hub
(Reporter)

Comment 2

5 years ago
I was thinking more along the lines: Is there something in our APIs that might make password fields exploitable even if people enter something? But wasn't sure, so better to be cautious than sorry. :) Thanks for clarifying!
(Assignee)

Comment 3

5 years ago
in Safari, "Secure Text Fields" return an empty value. We'll do the same with that patch.
(Assignee)

Comment 4

5 years ago
Created attachment 613848 [details] [diff] [review]
Intansiate the right class and set the proper subrole for password field. r=
(Reporter)

Comment 5

5 years ago
Comment on attachment 613848 [details] [diff] [review]
Intansiate the right class and set the proper subrole for password field. r=

I built with this patch locally, and can confirm that a) VoiceOver announces password fields as "Secure Edit text" and that b) it clicks when typing in a password into such a field. The text is then not reviewable, which is correct.
Attachment #613848 - Flags: feedback+
(Assignee)

Updated

5 years ago
Attachment #613848 - Flags: review?(trev.saunders)
Comment on attachment 613848 [details] [diff] [review]
Intansiate the right class and set the proper subrole for password field. r=

>-    
>+
>+  // A password text field return an empty value

nit, returns
Attachment #613848 - Flags: review?(trev.saunders) → review+
(Assignee)

Comment 7

5 years ago
Thanks. And I'll also fix the typo in the commit log. I'll land tomorrow morning.
(Assignee)

Updated

5 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 8

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/6c468f97100d
Target Milestone: --- → mozilla14
https://hg.mozilla.org/mozilla-central/rev/6c468f97100d
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.