Closed
Bug 24051
Opened 25 years ago
Closed 25 years ago
Modifying password field sometimes drops first character
Categories
(Core :: Layout: Form Controls, defect, P1)
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: morse, Assigned: mozeditor)
References
Details
(Whiteboard: [PDT+]partial fix in hand, code review needed)
Attachments
(1 file)
|
1.96 KB,
patch
|
Details | Diff | Splinter Review |
Load up a page containing the html shown below. Then do the following
experiments:
1. Enter a username and a password. Press the show-user button to display the
username and then the show-password button to display the password. Both
display correctly. So far, so good.
2. Position cursor at the end of the username field and erase entire field by
backspacing. Then reenter a new value. Do the same for password field. Again
display the two fields. Still correct.
3. Select the entire contents of the username field by sweeping the mouse over
it with the mouse button pressed. Type in a new value. Do the same for the
password field. Again display the two values. The username displays properly.
The password field is missing its leading character. THIS IS INCORRECT!
This bug affects single signon because if a user misenters his password the
first time he logs in and then returns to the login page to try again, the
incorrect password is already prefilled. He then reenters the password by
sweeping the mouse over it but his new entry will always be incorrect.
<HTML>
<BODY>
<FORM>
<TABLE>
<TR>
<TD>User Name</TD>
<TD><INPUT TYPE="TEXT" NAME="user"></TD>
</TR>
<TR>
<TD>Password</TD>
<TD><INPUT TYPE="PASSWORD" NAME="pswd"></TD>
</TR>
<TR>
<TD>
<INPUT
TYPE="BUTTON" VALUE="SHOW USER"
ONCLICK="alert(document.getElementById('user').value)">
</TD>
<TD>
<INPUT
TYPE="BUTTON" VALUE="SHOW PASSWORD"
ONCLICK="alert(document.getElementById('pswd').value)">
</TD>
</TR>
</TABLE>
</FORM>
</BODY>
</HTML>
Severity: normal → critical
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M14
setting to M14 in case I can't get a fix in tonight. Top priority bug.
attaching patch for partial fix.
it seems we were double-deleting the password backing data in the case of
extended-selection-plus-type-a-character. Joe, please see the attached changes
and verify that I've done the right thing given the rules code changes.
Basically, I removed the deletion portion of EchoInsertionToPWBuff(), since
mPasswordText is now maintained by the deletion code itself.
I say this is only a partial solution because we have one glaring hole left:
undo and redo. When transactions execute their undo and redo methods for a
password field, mPasswordText is never notified. So the password text will be
out of synch.
For M13, we could disable undo in password fields to make corruption impossible,
and re-enable it for M14 when we get our act together.
It gets worse...the undo portion of DeleteTextTransaction only knows about '*'
characters, it doesn't even remember the real text that was typed.
|
Assignee | |
Comment 6•25 years ago
|
||
aaaaaaaaaahhhhhhhhhhhhh!!!!!
I sure don't see an easy way out in the code for the undo/redo problem. I'm
pretty tempted to just disable undo in password fields. It's not very useful
anyway, since you can't see what the result of the undo really did.
Shuang, Beth: what do you think?
|
||
Comment 8•25 years ago
|
||
I agree with you Steve, undo/redo in a password field is a bit on the useless
side. I can't imagine that being high on any wish list. I would disable the
function.
|
Reporter | |
Comment 9•25 years ago
|
||
Certainly undo/redo on passwords is much less important than getting the
password right -- i.e., not dropping the first character.
Furthermore, I would argue that not only is undo/redo of passwords useless, its
probably wrong to even attempt to do it (you are editing in the dark). I agree
that this function should certainly be disabled, even if you were able to
support it and still solve the dropping-character problem.
|
|
Reporter | |
Updated•25 years ago
|
Summary: Modifying password field sometimes drops first character → [beta1] Modifying password field sometimes drops first character
|
|
Reporter | |
Comment 10•25 years ago
|
||
Oops, I just realized that I'm supposed to be adding the [beta1] notation to the
keywords field and not the summary line. Correcting this.
Keywords: beta1
Summary: [beta1] Modifying password field sometimes drops first character → Modifying password field sometimes drops first character
|
||
Comment 11•25 years ago
|
||
Putting on PDT+ radar for beta1
Whiteboard: partial fix in hand, code review needed → [PDT+]partial fix in hand, code review needed
|
||
Comment 12•25 years ago
|
||
marking potential beta1 bugs
|
|
||
Comment 13•25 years ago
|
||
assiging to joe to do the code review of the attached patch. also, joe what do
you think about just disabling undo/redo in a password field? others seem to
think it's ok, and it gets us out of a sticky mess. I've always sort of thought
undo/redo in a password field is useless anyway.
Assignee: buster → jfrancis
Status: ASSIGNED → NEW
|
|
Assignee | |
Comment 14•25 years ago
|
||
buster, if lovin' u is wrong, i dont wanna be right. I think turning off undo is
a good idea. accepting bug.
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 15•25 years ago
|
||
fixed. I went ahead and turned off undo for passwords as well. I couldn't do
this from inside the editor very cleanly, so I did it from gfx text control code
instead. Thanks buster! apologies for delay on checking this in....
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
||
Comment 16•25 years ago
|
||
I would like to check to see if problem has been fixed. Do I need to open test in
browser or editor ?
|
|
||
Comment 17•25 years ago
|
||
this is a browser issue.
|
|
||
Comment 18•25 years ago
|
||
Using the test case and instructions provided, this problem has been fixed.
Tested with 2000020908 build.
Status: RESOLVED → VERIFIED
| Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•