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

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Toolkit
Password Manager
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: tr.andrus, Assigned: zpao)

Tracking

({regression})

Trunk
mozilla1.9.3a1
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(status1.9.2 final-fixed, blocking1.9.1 -, status1.9.1 .8-fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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
Do you have a testcase or sample page which shows this bug?
(Reporter)

Comment 2

8 years ago
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

8 years ago
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

8 years ago
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
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.
Keywords: regressionwindow-wanted
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.
Component: General → Password Manager
Keywords: regressionwindow-wanted → regression
Product: Firefox → Toolkit
QA Contact: general → password.manager
Version: unspecified → 1.9.1 Branch
My guess is http://hg.mozilla.org/mozilla-central/rev/eb0decf65376 (bug 446109)
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

8 years ago
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

8 years ago
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

8 years ago
People, this is important.

*Please vote*

Dotan

Comment 12

8 years ago
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

8 years ago
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

8 years ago
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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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).
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.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 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

a192=beltzner
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 1.9.1.8 (nominate for .7, as I don't think the other flag is available yet)
blocking1.9.1: ? → -
Pushed http://hg.mozilla.org/releases/mozilla-1.9.2/rev/cbd0c874af9c
blocking1.9.1: - → ?
status1.9.2: --- → final-fixed
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: ? → -
status1.9.1: --- → wanted
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 1.9.1.8, 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 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a98c929dfad7
status1.9.1: wanted → .8-fixed
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.