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.
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.
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!
in Safari, "Secure Text Fields" return an empty value. We'll do the same with that patch.
Created attachment 613848 [details] [diff] [review] Intansiate the right class and set the proper subrole for password field. r=
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 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
Thanks. And I'll also fix the typo in the commit log. I'll land tomorrow morning.