Last Comment Bug 511474 - input type password loses value when gaining focus by tabbing from previous field
: input type password loses value when gaining focus by tabbing from previous f...
: regression
Product: Toolkit
Classification: Components
Component: Password Manager (show other bugs)
: Trunk
: All All
-- normal with 6 votes (vote)
: mozilla1.9.3a1
Assigned To: Paul O'Shannessy [:zpao] (not reading much bugmail, email directly)
: Matthew N. [:MattN] (PM if requests are blocking you)
Depends on:
Blocks: 446109
  Show dependency treegraph
Reported: 2009-08-19 11:49 PDT by tr.andrus
Modified: 2010-01-11 16:22 PST (History)
11 users (show)
paul: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch v0.1 (2.75 KB, patch)
2009-12-16 13:26 PST, Paul O'Shannessy [:zpao] (not reading much bugmail, email directly)
dolske: review+
mbeltzner: approval1.9.2+
dveditz: approval1.9.1.8+
Details | Diff | Splinter Review

Description User image tr.andrus 2009-08-19 11:49:50 PDT
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
Comment 1 User image Neil Deakin 2009-08-20 11:00:37 PDT
Do you have a testcase or sample page which shows this bug?
Comment 2 User image tr.andrus 2009-08-20 16:13:09 PDT
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
Comment 3 User image Cian Kinsella 2009-08-27 02:37:38 PDT
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
Comment 4 User image Dotan Mazor 2009-09-20 22:13:05 PDT
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.

Comment 5 User image Neil Deakin 2009-09-21 07:20:34 PDT
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.
Comment 6 User image (mostly gone) XtC4UaLL [:xtc4uall] 2009-10-07 18:02:50 PDT
this regressed within:

there are some PW Manager related checkins in that range.
Comment 7 User image Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2009-10-07 18:25:34 PDT
My guess is (bug 446109)
Comment 8 User image Justin Dolske [:Dolske] 2009-10-08 17:06:13 PDT
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?
Comment 9 User image Dotan Mazor 2009-10-10 13:37:07 PDT
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.

Comment 10 User image Chris Snyder 2009-10-10 14:25:52 PDT
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.
Comment 11 User image Dotan Mazor 2009-10-10 21:30:03 PDT
People, this is important.

*Please vote*

Comment 12 User image kovin 2009-10-19 06:57:30 PDT
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.
Comment 13 User image Wizard of Ogz 2009-12-14 22:20:10 PST
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)
Comment 14 User image Cian Kinsella 2009-12-15 12:34:18 PST
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.
Comment 15 User image Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2009-12-15 16:40:41 PST
Have a patch & am writing tests now.
Comment 16 User image Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2009-12-16 13:26:10 PST
Created attachment 417993 [details] [diff] [review]
Patch v0.1

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).
Comment 17 User image Justin Dolske [:Dolske] 2009-12-16 13:52:41 PST
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.
Comment 18 User image Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2009-12-16 22:00:29 PST

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.
Comment 19 User image Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2009-12-16 23:06:34 PST
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.
Comment 20 User image Mike Beltzner [:beltzner, not reading bugmail] 2009-12-17 15:29:46 PST
Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

Comment 21 User image Mike Beltzner [:beltzner, not reading bugmail] 2009-12-17 15:30:40 PST
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)
Comment 22 User image Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2009-12-17 15:51:18 PST
Comment 23 User image Daniel Veditz [:dveditz] 2009-12-18 11:25:54 PST
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.
Comment 24 User image Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2009-12-31 11:57:36 PST
Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

Applies cleanly to 1.9.1 & tests pass.
Comment 25 User image Daniel Veditz [:dveditz] 2010-01-08 13:46:18 PST
Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

Approved for, a=dveditz for release-drivers
Comment 26 User image Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2010-01-11 16:22:57 PST
Pushed to 191

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