Closed Bug 447788 Opened 15 years ago Closed 15 years ago

Login not filled if existing form username differs in case


(Toolkit :: Password Manager, defect)

1.9.0 Branch
Not set





(Reporter: Arronax50, Assigned: Dolske)





(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/2008071717 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/2008071717 Firefox/3.0.1

There's a problem with sites using MediaWiki (like Wikipedia) ou certain other sites such as 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.
Version: unspecified → 3.0 Branch
Most likely you have multiple logins stored, and so it doesn't know which one to fill in.

Enable logging per 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.
Closed: 15 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.
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).
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.
Product: Firefox → Toolkit
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1
Attached patch Patch v.1Splinter Review
Obvious fix. Also verified that the code dealing with the autocomplete dropdown is already case-insensitive.
Attachment #337148 - Flags: review?(
Whiteboard: [need review gavin]
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?( → review+
Pushed changeset 57feb1188e7d.
Closed: 15 years ago15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need review gavin]
Target Milestone: mozilla1.9.1 → mozilla1.9.1b1
Depends on: 475943
Depends on: 499649
(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.