Last Comment Bug 721001 - [Mac] password entry fields not identified as such, entering password does not generate typical audible click
: [Mac] password entry fields not identified as such, entering password does no...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86_64 Mac OS X
: P1 normal (vote)
: mozilla14
Assigned To: Hubert Figuiere [:hub]
:
: alexander :surkov
Mentors:
Depends on:
Blocks: osxa11y
  Show dependency treegraph
 
Reported: 2012-01-25 06:05 PST by Marco Zehe (:MarcoZ)
Modified: 2012-04-13 04:23 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Intansiate the right class and set the proper subrole for password field. r= (3.18 KB, patch)
2012-04-10 19:11 PDT, Hubert Figuiere [:hub]
tbsaunde+mozbugs: review+
mzehe: feedback+
Details | Diff | Splinter Review

Description Marco Zehe (:MarcoZ) 2012-01-25 06:05:10 PST
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.
Comment 1 Daniel Veditz [:dveditz] 2012-01-25 13:05:52 PST
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.
Comment 2 Marco Zehe (:MarcoZ) 2012-01-25 23:07:23 PST
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!
Comment 3 Hubert Figuiere [:hub] 2012-04-10 19:08:26 PDT
in Safari, "Secure Text Fields" return an empty value. We'll do the same with that patch.
Comment 4 Hubert Figuiere [:hub] 2012-04-10 19:11:34 PDT
Created attachment 613848 [details] [diff] [review]
Intansiate the right class and set the proper subrole for password field. r=
Comment 5 Marco Zehe (:MarcoZ) 2012-04-11 02:00:13 PDT
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.
Comment 6 Trevor Saunders (:tbsaunde) 2012-04-11 22:24:23 PDT
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
Comment 7 Hubert Figuiere [:hub] 2012-04-11 22:26:42 PDT
Thanks. And I'll also fix the typo in the commit log. I'll land tomorrow morning.
Comment 9 Marco Bonardo [::mak] 2012-04-13 04:23:47 PDT
https://hg.mozilla.org/mozilla-central/rev/6c468f97100d

Note You need to log in before you can comment on or make changes to this bug.