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

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect)

Description

[tr.andrus]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.39 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

[Neil Deakin]

Do you have a testcase or sample page which shows this bug?

Comment 2

[tr.andrus]

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

[Cian Kinsella]

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

[Dotan Mazor]

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:
http://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=390546&forumId=1

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.

Dotan

Comment 5

[Neil Deakin]

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

[(mostly gone) XtC4UaLL [:xtc4uall]]

this regressed within:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-06+06%3A23&enddate=2008-09-07+03%3A26

there are some PW Manager related checkins in that range.

Comment 7

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

My guess is http://hg.mozilla.org/mozilla-central/rev/eb0decf65376 (bug 446109)

Comment 8

[Justin Dolske [:Dolske]]

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

[Dotan Mazor]

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.

Dotan

Comment 10

[Chris Snyder]

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

[Dotan Mazor]

People, this is important.

*Please vote*

Dotan

Comment 12

[kovin]

I can confirm this behavior in Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) 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

[Wizard of Ogz]

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:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)

Comment 14

[Cian Kinsella]

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

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Have a patch & am writing tests now.

Comment 16

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Attachment: 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

[Justin Dolske [:Dolske]]

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

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Pushed http://hg.mozilla.org/mozilla-central/rev/3c005772de0c

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

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

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

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

a192=beltzner

Comment 21

[Mike Beltzner [:beltzner, not reading bugmail]]

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 1.9.1.8 (nominate for .7, as I don't think the other flag is available yet)

Comment 22

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Pushed http://hg.mozilla.org/releases/mozilla-1.9.2/rev/cbd0c874af9c

Comment 23

[Daniel Veditz [:dveditz]]

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

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

Applies cleanly to 1.9.1 & tests pass.

Comment 25

[Daniel Veditz [:dveditz]]

Comment on attachment 417993 [details] [diff] [review]
Patch v0.1

Approved for 1.9.1.8, a=dveditz for release-drivers

Comment 26

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Pushed to 191 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a98c929dfad7