Closed Bug 511474 Opened 13 years ago Closed 13 years ago

input type password loses value when gaining focus by tabbing from previous field


(Toolkit :: Password Manager, defect)

Not set



Tracking Status
status1.9.2 --- final-fixed
blocking1.9.1 --- -
status1.9.1 --- .8-fixed


(Reporter: tr.andrus, Assigned: zpao)



(Keywords: regression)


(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/ Safari/530.5
Build Identifier: 3.5

this only happens when user changes the value of the previous field by typing manually, then tabs to the input type password

Reproducible: Always

Steps to Reproduce:
1. create form with email and password fields
2. autopopulate fields on page load based on user info
3. change the email address and tab to the password field

Actual Results:  
password field loses its value upon gaining focus

Expected Results:  
password field should retain its prepopulated value
Do you have a testcase or sample page which shows this bug?
unfortunately it is internal and i cannot give you access. i tested this same case using 3.0.13 and it didn't happen, so i presumed that it must be a bug with 3.5. This only happens in FF, not in IE or Safari
Yes, I experienced this as well.  It is happening with 3.5.2.  It is happening whenever the text box above the password loses focus (or just after to be precise, because the value is still intact at the onblur event).

I worked around it in javascript by saving the password value after load and on change, and scheduling (via setTimeout) a restore of the password 100 milliseconds after the textbox onblur event
Happens on all websites that require a password.

Reproduce? Easy:
1. Go to any web site that saved a user name and a password.
2. Go to the user name field, and change 1 of the letters.
3. Watch the password drift away, into oblivion.

See thread here for more examples:

Extremely problematic when you want to edit a page that has users details in it, and the password field gets cleared. You have no idea what the password was, so you have to reset the password and notify the user.

Please advise.

Seems that the autocomplete is looking for a match for the changed username in the set of stored passwords, not finding one, so clearing the password field.
this regressed within:

there are some PW Manager related checkins in that range.
Component: General → Password Manager
Product: Firefox → Toolkit
QA Contact: general → password.manager
Version: unspecified → 1.9.1 Branch
Hmm, I thought there was already a bug on this; sounds familiar.

We explicitly clear the password field, on the expectation that we're about to fill in some login (clearing the field ensures the fillin doesn't fail, as it could if we're autofilling a form during pageload).

Sounds like we missed a case for blurring the username field without selecting a login?
Whenever a user goes into a password field, it's either by mouse or by using the TAB button.

If it's by mouse, then one can only assume that the user is not a power user (no offense, please), and therefore this user has a low chance of needing to remember to delete the password field.

If it's by using the TAB button, then the password will be automatically selected, and deleted as the first character is entered.


This used to be the way that Firefox worked.

It was great.

People got used to it.

Everyone I know are confused with the new 'feature'.

Please bring the good original behavior back.

The assumption here is that password fields are only used on login forms, and that's simply not the case.

I experience this as a bug on an admin interface where I edit user records. The form looks like this (stars for password fields):

Full Name: _____
Email: ______
Password: *****
Confirm: *****
Website: ______

The password fields are pre-loaded with the value "same", which causes the system to ignore them. (Yes, I know this could be implemented in different ways; my boss prefers this for some reason.)

Point is, if you change the Email field and then tab, the Password field gets cleared. 

This is not expected behavior. This form has nothing to do with login. There is no username field. Please fix.
People, this is important.

*Please vote*

I can confirm this behavior in Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2.

This behavior is not a feature, it's a bug. I have a situation similar to the one pointed out by Chris Snyder and it's very annoying.
I have also noticed this behavior occurs when the password field is the next input field in the DOM (haven't tested whether level matters) after the username text field.  As a work-around I added a hidden input between the username and password fields in my forms.  It would also be possible to reorder the input fields.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
Mmm what does it take for a bug to exit the "unconfirmed" status?  Before long, the population of web forms will be full of workarounds like hidden fields to avoid this silly behaviour.  We have standards and FF was previously in the forefront of applying them rigidly.  Now they've caught the MS bug - they want to make lots of decisions on behalf of the users on how they should behave.
Have a patch & am writing tests now.
Assignee: nobody → paul
Ever confirmed: true
Attached patch Patch v0.1Splinter Review
Only the one test because it's painful to find the right place in any other test. It could probably do with a test that isn't in autocomplete, but if we regress this again, the autocomplete test should catch it regardless (the new test fails without the patch).
Attachment #417993 - Flags: review?(dolske)
Attachment #417993 - Flags: review?(dolske) → review+
Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

>+        sendChar("A", uname);
>+        // Trigger the 'blur' event on uname
>+        pword.focus();
>+        checkACForm("singleuser5A", "singlepass5");

Nit: other tests have "user1A", "user1B", etc... Change the sendChar to add an "X" instead so there's no confusion.

We should probably try to get this onto 1.9.2 (we're not at RC yet!) and 1.9.1 since this is a regression.
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Version: 1.9.1 Branch → Trunk
blocking1.9.1? since this regressed between 1.9.0 and 1.9.1. It's tested and even though we're so close to 3.6 there will be a number of users on 3.5 for a while.
blocking1.9.1: --- → ?
Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

Attachment #417993 - Flags: approval1.9.2+
I don't think this blocks any 1.9.1 release, but if you put together a branch patch and ask for approval, it might get taken for (nominate for .7, as I don't think the other flag is available yet)
blocking1.9.1: ? → -
Agree w/beltzner: we won't hold the next release for this ("blocking") but if you're ready to land a fix you can request approval on a merged patch.
Blocks: 446109
blocking1.9.1: ? → -
Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

Applies cleanly to 1.9.1 & tests pass.
Attachment #417993 - Flags: approval1.9.1.8?
Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

Approved for, a=dveditz for release-drivers
Attachment #417993 - Flags: approval1.9.1.8? → approval1.9.1.8+
Whiteboard: [needs 1.9.1 landing]
Pushed to 191
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [needs 1.9.1 landing]
You need to log in before you can comment on or make changes to this bug.