Closed Bug 447788 Opened 14 years ago Closed 14 years ago
Login not filled if existing form username differs in case
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/2008071717 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/2008071717 Firefox/3.0.1 There's a problem with sites using MediaWiki (like Wikipedia) ou certain other sites such as www.clubic.com. I login using my account name which starts with a lower case letter. The password manager stores the login/password. When I go to the website again, the login form isn't filled, the user name and password fields are blank. I have to manually enter the first letters of the logname and click on the newly appeared text popup that contains my whole user name below the user name field in order to have the password and logname appear (I have of course only one accout on these sites). This bug only concerns some websites, on Linux (haven't tested elsewhere), when my username starts with a minuscule. So I store my username with an upper case letter since it doesn't seem to be case-sensitive, but it's only a workaround. Reproducible: Always Steps to Reproduce: 1. create an account on a MediaWiki powered website 2. use a login name starting with a lower case letter (e.g. arronax) 3. store the password in Firefox with the built-in password manager 4. log out the site 5. go to the login page Actual Results: No prefilled login fields. Expected Results: Prefilled login fields. Default theme. Ubuntu 8.04 x64.
Most likely you have multiple logins stored, and so it doesn't know which one to fill in. Enable logging per http://wiki.mozilla.org/Firefox:Password_Manager_Debugging and attach here.
Attachment #331155 - Attachment mime type: application/octet-stream → text/plain
Here's the problem: Login Manager: Password not filled. None of the stored logins match the username already present. When I go to the site, there's a username field with "Pseudo" already present in the field. [The site is French, and I assume "pseudo" is the .fr equivalent of "username"] We don't fill in the field when there's a value already present. It seems a bit silly in this case, but in other case it's a legitimate value.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
There's a similar bug on Wikipedia. The username field is already filled with "Arronax50" and Firefox doesn't want to show the password because it is stored with "arronax50" as username.
If the value you're seeing already-filled in the page is your username (not the "Pseudo" I was getting), then I'd recommend deleting you existing login, and saving it again with the case as the site is expecting. Usernames can be case-sensitive in other contexts, so offhand I don't think we'd want to do a case-insensitive comparison.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Ok, I've changed my mind. :) We can probably do a case-insensitive comparison when filling the form. This would mean that if you had logins for both "USER" and "user", that we might prefill the wrong one when the page suggests a proper value. But that's probably rather uncommon, and the rest of the code will preserve case in stored logins. The main problem I was worried about was if doing this could cause interactions resulting in saving duplicate logins for "myname" and "Myname". But I don't think that's the case (and may even help avoid it).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → dolske
Summary: password manager doesn't fill relevant fields when using a login starting with a lower case letter on certain websites → Login not filled if existing form username differs in case
Concerning Wikipedia (that behavior appears in every Wiki using mediawiki, like my own) : "If the value you're seeing already-filled in the page is your username" It's my username, but capitalized, so I have to change the first letter in order to have the password appear on screen. As Firefox doesn't seem to capitalize stored form text I think it's a MediaWiki bug (not really a bug, but a mistake given Firefox behavior). Because the (wrong & capitalized) login appear on wikipedia's 'open session' page even when I suppress form data.
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1
Obvious fix. Also verified that the code dealing with the autocomplete dropdown is already case-insensitive.
Attachment #337148 - Flags: review?(gavin.sharp)
Won't this result in an additional "Do you want to remember" prompt for the username with the difference case when you submit the form?
Nope. The code still fills in the username from the selected login [see end of _fillForm()]. Note that the testcase has <input name="uname' value='TESTUSER'>, and verifies that when the page is loaded the field value is "testuser" (lowercase), in addition to the password having been filled in.
Attachment #337148 - Flags: review?(gavin.sharp) → review+
Pushed changeset 57feb1188e7d.
Status: NEW → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Whiteboard: [need review gavin]
Target Milestone: mozilla1.9.1 → mozilla1.9.1b1
(In reply to comment #11) > Pushed changeset 57feb1188e7d. We REALLY need to roll this fix back. It makes the password manager unusable in cases where the user has usernames that differ only in case. You might argue that they shouldn't do that, but the comments in 499649 make it clear that it DOES happen. Now that this 'fix' is in place, there is NO workaround other than disabling saved passwords entirely for that site
Yes, yes, yes, please undo this unfortunate fix. I don't think it is Firefox's job to put in some business logic to deal with WikiMedia's choice to pre-fill the user names with a different case. Or even to decide that user names are case-insensitive. What I worry about is that the change was pushed 2008-09-06 but was distributed only in mid-2009. I don't want to wait another year for the problem to be fixed. Is there any workaround?
You need to log in before you can comment on or make changes to this bug.