56118 - INPUT with type of password is read out loud

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[cpratt]

Build ID: Netscape 6 PR3
Platform: Windows 2000 with Narrator (screen reader utility for the visually 
impaired)

To reproduce:
- If Narrator isn't running, start it by typing NARRATOR at a command prompt
- Make sure that the "Read typed chaaracters" feature is checked
- Load the URL above (I will also attach it to this bug report for non-NSCP 
people)
- Click into the Password field in the form. Start typing (slowly).

Result: Every letter you type is read out loud. This is a security issue 
because it means the password you're typing isn't masked.

Expected result: If you use IE 5.5, you'll note that every character "read" is 
replaced by the phrase "password". This is the correct result.

Comment 1

[cpratt]

Attachment: HTML file with input type password in form

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Reporter: this should probably be assigned to the owner of the Narrator program,
whoever that is.

Comment 3

[cpratt]

Narrator is a component of Windows operating systems. It functions correctly 
with IE 5.5 and Communicator 4.76. I'm not sure I understand your comment.

Comment 4

[sairuh (rarely reading bugmail)]

steve, should this go over to Password Manager (single signon)?

Comment 5

[Stephen P. Morse]

No, it's definitely not a single-signon problem.

Comment 6

[Mitchell Stoltz (not reading bugmail)]

I'm not sure who this should go to, because I don't know how Narrator ties in to
our code. It must do more than just sniff keystrokes, if it can tell whether the
user is typing in a password field or not. Who knows about lower-level Windows
stuff like this?

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Reassigning to layout for further triage; I have no idea who this should be
assigned to.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I discussed this a bit with joki, jst and pollmann. Our guess is that the
NARRATOR knows what is a password field because normal Windows applications use
the standard text control which has some flag to hide the text, i.e. make it
"password field".

Now, with our XUL story we have just one huge window for the whole content area
(from Windows' perspective). A horrible hack solution for this bug might be to
convert the whole window into a Windows password window just for the time to
handle the key press in our password field (not sure if this is possible, it
would be nice if we could just add/remove some flag to the window). Or return
back to native "password" widget.

In any case, it is probably widget folks who should deal with this.

Comment 9

[Peter Trudelle]

->html form controls, added access keyword.

Comment 10

[Aaron Leventhal]

This bug should go away once we support full accessiblity, either through MSAA,
external DOM api or internal scripts.

Comment 11

[Vladimir Ermakov]

QA Contact Update

Comment 12

[rods (gone)]

I am reassigning this over to editor. When accessability asks for the contents 
of the text field and it is a password, it should return "*" for the value 
instead of the actual text. If this is working correctly, then mark as WFM.

Beppe, you should have eric test this or reassign this bug to him.

Comment 13

[rubydoo123]

the password data is being inserted into the password field correctly, how 
Narrator interprets that data is beyond the scope of text insertion. The 
assistive technology software needs to be made aware of the XUL content or the 
DOM content. I would suspect that the DOM node has a notion that it is a 
password field. A flag of sorts is set by the type=password attribute 
name/value pair, which the assistive technology application should sniff.

I am in the process of contacting Microsoft to see if someone from the 
development group over there can tell us what needs to be passed so the Narrator 
application can work correctly.

Comment 14

[cpratt]

aaronl, will this be fixed once we do the things necessary to work with active 
accessibility? I don't see what this has to do with Editor; doesn't this more 
have to do with properly telling the OS that the custom control used is one of 
type password? (Or something like that; I'm fuzzy on the details here.)

Comment 15

[Aaron Leventhal]

The actual bug only occurs as the user types. Each letter they type is spoken.
This is happening before Mozilla even gets the key. It's not a bug with reading
the screen contents.

However, if the accessibility aid can query and find out that it is indeed a
password field (via our MSAA support), it might do the right thing and not read
the typed keystrokes. If it's still a problem then, we'll have to ask the makers
of JAWS, WindowEyes, etc. to pay attention to the MSAA password value.

So yes, I'll take this bug.

Comment 16

[timeless]

on windows2000 there's an event before normal key events, you might be able to 
intercept there.

Comment 17

[Peter Trudelle]

->mozilla0.9.1/p3

Comment 18

[Aaron Leventhal]

The suggested solution did not work. I am awaiting a response from Mike Friedman 
of Microsoft Accessibility about what we need to do here.

Comment 19

[Aaron Leventhal]

Fixed.

Comment 20

[Vladimir Ermakov]

verifying fixed 2001-07-10-05-0.9.2