User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/18.104.22.168 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
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.
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
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. Dotan
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* Dotan
I can confirm this behavior in Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124) 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:126.96.36.199) 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
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)
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: 9 years ago
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 188.8.131.52 (nominate for .7, as I don't think the other flag is available yet)
blocking1.9.1: ? → -
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.
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: approval184.108.40.206?
Comment on attachment 417993 [details] [diff] [review] Patch v0.1 Approved for 220.127.116.11, a=dveditz for release-drivers
Attachment #417993 - Flags: approval18.104.22.168? → approval22.214.171.124+
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.