Firefox auto-completes login fields in a case-insensitive manner

Bug #480671 reported by Olivier Tilloy
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox-3.5 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: firefox-3.5

If I have two username/password pairs for two web applications in the same domain (say http://example.com/app1/login and http://example.com/app2/login), and if the usernames happen to differ only in the case (say "Foo" for app1 and "foo" for app2), whenever I try to login to app2 the auto-completion feature will always change "foo" to "Foo". Whether I manually type it in completely or select it from the dropdown list doesn't make a difference, I'm unable to enter the correct username and therefore to login. I didn't find any magic combination of keys to work it around.

I didn't test but I guess the same happens when the two usernames are used for the same application as well.

ProblemType: Bug
Architecture: i386
Date: Wed Nov 11 13:07:06 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: firefox-3.5 3.5.4+nobinonly-0ubuntu0.9.10.1
ProcEnviron:
 LANGUAGE=fr_FR.UTF-8
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-15.49-generic
SourcePackage: firefox-3.5
Uname: Linux 2.6.31-15-generic i686

Revision history for this message
In , Pelzowski (pelzowski) wrote :

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5

Kadu.net has a Wiki (MediaWiki) site and phpbb forum.

On Wiki site ( http://www.kadu.net/wiki/index.php?title=Specjalna:Zaloguj&returnto=Main_Page ) I have login starting with upper case, like "Alogin" and pasword "A"
On the forum ( http://www.kadu.net/forum/ucp.php?mode=login ) I have the same login but starting with lower case, like "alogin" and different password "B".

In Firefox3 RC2 I can't login on Wiki site with "Alogin". Typing "Alogin" switches me to "alogin" from forum, which is remembered by Firefox.

Reproducible: Always

Steps to Reproduce:
1. Login to forum with "alogin" and password "B". Remember password in firefox. [ http://www.kadu.net/forum/ucp.php?mode=login ]
2. Go to Wiki, try to login with "Alogin" and pasword "A" [ http://www.kadu.net/wiki/index.php?title=Specjalna:Zaloguj&returnto=Main_Page ]

Actual Results:
Typing "Alogin" and password "A" and clicking enter switches to "alogin" and password from forum.

Expected Results:
Possibility to have sililar "alogin" and "Alogin" with different passwords.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

*** Bug 499715 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

*** This bug has been marked as a duplicate of bug 499649 ***

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

I guess this is a duplicate of bug 475943, but given the duplicates I'm not sure we'll be able to get away with WONTFIX...

Revision history for this message
In , Dolske (dolske) wrote :

Bug 447788 change this behavior, so that login manager works better on Wikipedia.

I'm not sure there's a good fix here. The first order problem is that the user has saved an incorrect login. It would be good to have a nice way to correct the problem, but the only two solutions that come to mind are:

1) Backout 447788 so you can save multiple logins that differ only in case

2) Modify the saved login's username (eg from "Myname" to "myname") when the user corrects & submits a login form using it. We normally never change a login's username, but maybe this is a special case. But it would need confirmation UI, which is going to end up being kind of confusing.

Revision history for this message
In , Wildmyron (wildmyron) wrote :

(In reply to comment #3)
> 2) Modify the saved login's username (eg from "Myname" to "myname") when the
> user corrects & submits a login form using it. We normally never change a
> login's username, but maybe this is a special case. But it would need
> confirmation UI, which is going to end up being kind of confusing.

This approach wouldn't fix bug 499715 which has been marked as a duplicate of this bug.

Revision history for this message
In , Pkextern (pkextern) wrote :

*** Bug 501323 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Majuki (majuki) wrote :

I would recommend a backout of 447788 entirely. User can also have case sensitive user names that are identical. ie: Username with password A logs in as their administration, username with password B logs in as their standard user account.

With 447788 Firefox is attempting to accommodate a specific set of scenarios while ignoring others specific scenarios. The patch also screws up saved passwords where a site administrator changes from case-insensitive to case-sensitive. Previously entered usernames now become invalid and must be corrected but cannot because Firefox auto-corrects to the saved username/password.

I think a simple logic change may eliminate the issues entirely:

If the password was filled in -> onUserNameFormFieldChange if strToLower(username) === strToLower(stored username) && username !== stored username then prompt "Update|Save As New|Not Now|Never for this site" - if change, update username.

Either way, if a change is made to the username field by the user Firefox should never overwrite this change.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

*** Bug 503000 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Paul-oshannessy (paul-oshannessy) wrote :

*** Bug 506365 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Ria-klaassen (ria-klaassen) wrote :

*** Bug 506931 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Acraigwest (acraigwest) wrote :

I would have to argue with either backing out 447788, or possibly adding a new setting, possibly on a site-by-site basis to allow case-insensitive username matches. Justin said in the earlier WONTFIX bug "We're kind of screwed no matter which way we do things, but I think the current behavior is better. Having multiple accounts (with different passwords) that differ only in case is already full of fail for a multitude of reasons, so I'm not really inclined to want to support that use-case."

The problem is that there are users WITH that use case, and in the current state, there is nothing they can do. With the previous state of the code, you could always delete the password entry with the wrong case and things would work as they should. Right now, if, for some reason, you need to have two usernames distinguished only by case, you CAN'T.

Revision history for this message
In , Thom-aboutlanguage (thom-aboutlanguage) wrote :

It seems most likely that this situation only occurs when the user enters a userID that is case-sensitive and does not match the case also specified to the server. Firefox then tries to "help" the user by selecting the bad ID that was previously entered.

If there were some easy way to get Firefox to forget a particular entry, I think this would solve the problem. I would love to be able to get the list that Firefox is offering, then point to the bad item and hit delete.

Revision history for this message
In , Acraigwest (acraigwest) wrote :

There are actually two separate problems covered by this bug. You may have found a third, actually... The two I know of are the case where the saved username has the incorrect case stored, and the case where the user wishes to save two different usernames for the same site, that differ only by case. In the first of these, the user can delete the bad entry from the stored passwords list, so it isn't a problem, really. The second case is the one that I would say requires backing out 447788.
Assuming your (Thom) problem is caused by the saved password list, then you just need to go to the Preferences/Options Security tab, under saved passwords.
The possible third case that you may be introducing would be if your problem is being introduced by the form entry memory feature, in which case it is probably a separate bug

Revision history for this message
In , Pelzowski (pelzowski) wrote :

In response to comment #12
"(...) and the case where the user wishes to save two different usernames for the same site, that differ only by case."

In bug submitted by me, https://bugzilla.mozilla.org/show_bug.cgi?id=499715 Firefox have to deal with different use case. There is one domain with two different service installations (phpbb forum and MediaWiki site), those are completely separated applications from user point of view (registration is independent). As a result having different passwords for forum and MediaWiki is not an odd user case IMO.

Having multiple accounts that differ only in case, in #499715 example, also is explainable. Why? Because MediaWiki installation by default is creating user logins starting with upper case... So MediaWiki is creating "Alogin" logins.

It wasn't my choose to have similar login with upper case and lower case difference, MediaWiki created upper case login AFAIR.

After upgrading Firefox to 3.5 in this situation (with different passwords set for Forum and Wiki) I had to do this steps to bypass login problems:
1) Login into MediaWiki with other web browser, change password for the same password as on Forum
2) In Firefox3.5 Go to the Preferences/Options Security tab and delete upper case login (Media wiki's one)
3) From now on login to forum and Media Wiki with lower case login
Third step works only because, as i realised today, when I login with "alogin" into MediaWiki it will also work (MediaWiki is redirecting proper "Alogin" to "alogin" which i wasn't aware of...)

Having multiple accounts (with different passwords) that differ only in case is
already full of fail for a multitude of reasons, so I'm not really inclined to
want to support that use-case."

Having multiple accounts (with different passwords) that differ only in case is
already full of fail for a multitude of reasons, so I'm not really inclined to
want to support that use-case."

So AFAIR this bug doesn't apply only to the same site, but to the same domain.

Revision history for this message
In , Thom-aboutlanguage (thom-aboutlanguage) wrote :

Thanks to A Craig West's tip (thanks!), I've deleted the offending item in the password list and my personal problem is now over (at least the one concerning FireFox).

Revision history for this message
In , Rfc469 (rfc469) wrote :

As described in comment #10... This prevents me from logging in to my YouTube account (or alternatively my Google/Gmail account) because my YouTube and Google usernames differ only by case and the YouTube login page was somewhat recently moved to the google domain. Yes, I can tell firefox to never remember passwords for the google domain but it worked perfectly with 3.0.x which supported differing-case usernames for a domain.

Revision history for this message
In , Tttttg (tttttg) wrote :

Please back out the fix for bug 447788 !!!

On some sites I have user accounts that differ only by the first character case ("Mylogin"/"mylogin"). Both are stored in the password manager (using older versions of Firefox). Now when I try to login using "mylogin" Firefox always *replaces* my input by "Mylogin" and puts wrong password in the password field.

When a user "accidently saved login with incorrect case" (bug 447788) he can fix it very easily by removing the entry in the password manager. However with the current "fix" to bug 447788, it is not possible to use the password manager at all in a situation with multiple logins that differ only in case. The only option is to remove both entries and use some external password manager.

The current behavior is far worse because it can't be corrected by user, unlike the situation described in bug 447788.

Revision history for this message
In , Acraigwest (acraigwest) wrote :

I think the best fix for this is as stated in comment 6,
"If the password was filled in -> onUserNameFormFieldChange if
strToLower(username) === strToLower(stored username) && username !== stored
username then prompt "Update|Save As New|Not Now|Never for this site" - if
change, update username.

Either way, if a change is made to the username field by the user Firefox
should never overwrite this change."
This seems to deal with both this problem, and the original problem for bug 447788.

Revision history for this message
In , Paul-oshannessy (paul-oshannessy) wrote :

*** Bug 516037 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Ria-klaassen (ria-klaassen) wrote :

*** Bug 516646 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Piyu-aryan (piyu-aryan) wrote :

Yes That is what i want.

When the Fix will be available??
in newer version or Patch will be provided?

(In reply to comment #6)
> I would recommend a backout of 447788 entirely. User can also have case
> sensitive user names that are identical. ie: Username with password A logs in
> as their administration, username with password B logs in as their standard
> user account.
>
> With 447788 Firefox is attempting to accommodate a specific set of scenarios
> while ignoring others specific scenarios. The patch also screws up saved
> passwords where a site administrator changes from case-insensitive to
> case-sensitive. Previously entered usernames now become invalid and must be
> corrected but cannot because Firefox auto-corrects to the saved
> username/password.
>
> I think a simple logic change may eliminate the issues entirely:
>
> If the password was filled in -> onUserNameFormFieldChange if
> strToLower(username) === strToLower(stored username) && username !== stored
> username then prompt "Update|Save As New|Not Now|Never for this site" - if
> change, update username.
>
> Either way, if a change is made to the username field by the user Firefox
> should never overwrite this change.

Revision history for this message
In , Rfc469 (rfc469) wrote :

Is there any hope for this regression being fixed in 3.5.4 (or in the near future)?

Revision history for this message
In , saurabh (faplap) wrote :

> Either way, if a change is made to the username field by the user Firefox
> should never overwrite this change.

Exactly - I don't understand why this is such a difficult fix. The problem is that firefox is overwriting MY choice of case, either when I type it by hand, or when I select it from the drop-down list of completion choices firefox presents me (even more bizarre!). Match case FIRST, then if that fails (and ONLY if that fails) look for a case-insensitive option to complete. Not too hard to do, and solves both bugs.

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 527233 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Scouterjoe5 (scouterjoe5) wrote :

Is this the same underlying cause of the problem where an initial value in a username or password field (for example 'Email' and 'Password') would cause the password manager to fail to supply the appropriate credentials automatically because it thinks it's trying to match a password to the initial value? Or is there a separate bug report for such a problem?

Revision history for this message
Olivier Tilloy (osomon) wrote :

Binary package hint: firefox-3.5

(may be related to bug #469981)

If I have two username/password pairs for two web applications in the same domain (say http://example.com/app1/login and http://example.com/app2/login), and if the usernames happen to differ only in the case (say "Foo" for app1 and "foo" for app2), whenever I try to login to app2 the auto-completion feature will always change "foo" to "Foo". Whether I manually type it in completely or select it from the dropdown list doesn't make a difference, I'm unable to enter the correct username and therefore to login. I didn't find any magic combination of keys to work it around.

I didn't test but I guess the same happens when the two usernames are used for the same application as well.

ProblemType: Bug
Architecture: i386
Date: Wed Nov 11 13:07:06 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: firefox-3.5 3.5.4+nobinonly-0ubuntu0.9.10.1
ProcEnviron:
 LANGUAGE=fr_FR.UTF-8
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-15.49-generic
SourcePackage: firefox-3.5
Uname: Linux 2.6.31-15-generic i686

Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Olivier Tilloy (osomon) wrote :
Changed in firefox-3.5 (Ubuntu):
status: New → Confirmed
description: updated
Revision history for this message
Gabe Gorelick (gabegorelick) wrote :

Bug #469981 is in fact a duplicate of this one.

Revision history for this message
In , Jo-hermans (jo-hermans) wrote :

*** Bug 554792 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Jo-hermans (jo-hermans) wrote :

*** Bug 510573 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Oq9pscb02 (oq9pscb02) wrote :

This is a serious problem because it locks users out of web sites and applications.

A quickfix would would be to skip the autochange of the username when I escape out of the dropdown list.

Changed in firefox:
status: Unknown → Confirmed
Revision history for this message
In , Toub (n-toublanc) wrote :

I had to fight several times against this bug for a simple reason.

1) register to a web site chossing the login "MyLogin" and the password "xxx".
2) Firefox suggest to remember the password, I choose YES
3) I receive the confirmation link by mail and I try to login
4) It does not work because the web site automatically converted "MyLogin" to "mylogin"

e.g. http://joomlacode.org

When I choose to enter "mylogin", if I do not explicitly choose the suggested value "MyLogin", Firefox should NOT automatically change my entered value in the form!

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 555933 has been marked as a duplicate of this bug. ***

Revision history for this message
In , P (p92) wrote :

it's a pity this annoyance still exist in 3.6.8 ! I am also affected by the case sensitive userid login.

For me the problem is the impossibility to ESCAPE from firefox automatic choice choice even if I press ESC when firefox propose a list of users. as soon as I change from the username field to the password field firefox fills both fields with the case insensitive match and there is NO POSSIBILITY to AVOID this behaviour.

I also agree that this was really better working before.

I agree with comments #28 #27 #22 #20 #17

This bug is a showstopper for firefox - a program should not overwrite the user's will !

Revision history for this message
In , Wildmyron (wildmyron) wrote :

*** Bug 590446 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

*** Bug 595587 has been marked as a duplicate of this bug. ***

Changed in firefox:
importance: Unknown → Medium
Revision history for this message
In , Mvel (mvel) wrote :

Completely agree with all latest comment. This behavior disturbs our testers' work, but we love Fx and believe this is a greatest browser. In addition, we currently cannot switch to another browser.

Imho, comment #24 provides the clear algo for fixing all these problems.

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 637784 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Alice0775 (alice0775) wrote :

*** Bug 641771 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Mozilla-e (mozilla-e) wrote :
Download full text (4.8 KiB)

I'd like to suggest a fix for this bug.

This bug appeared with the fix of bug 447788 somewhere around version 3.5.

In bug 447788 the problem seems to be that when you register on a mediawiki Wiki site, you can register using a lowercase user name, "john" but the site then pre-fills the user name using an initial capital, "John". The complain, if not mistaken, was that the password, even though it was saved, was not auto-filled. The reason was that Firefox did not match username "John" with the saved username "john".

The fix was to make the whole password manager case insensitive. Justin Dolke noted: "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)." But since then there have been numerous complaints about Firefox forbidding logins with different cases.

So I'd like to suggest the following behavior for the case-sensitivity problem:

User name auto-fill
- FF has a method that identifies a password field and the associated username field.
- If the username is blank and FF has a single username/password saved for that web page, then the username and password should be auto-filled from the saved username. That should happen when the page loads.
- In no circumstance should FF change the username that was pre-filled by the web site or entered by the user.

Password autofill
- If the username gets autofilled when the page loads, the password should be auto-filled at the same time.
- If the username was pre-filled by the web site, and the username matches a saved username/password, then the password should be auto-filled when the page loads.
- When leaving the username field, if the username field was changed and the username matches a saved username/password, then the password should be auto-filled with the saved password.
- Which username "matches" a saved username/password is described below.

Saved usernames/passwords
- A flag "case-insensitive" tells that a saved username/password entry also applies to all alternate cases for the username.
- A username that is marked case-insensitive cannot appear with a different case among saved usernames/passwords.

Matching usernames with saved usernames
- A saved username matches the exact same username or, if the flag is set, any username that is equal ignoring case.

Saving the password
- When a user submits a form:

  - If the web page is flagged never to save passwords, do nothing

  - If the username matches a saved username/password and the password matches, do nothing.

  - If there is no matching username saved for that web site, ask the usual question:
      "Remember password for user "xxx" on yyy?" with options "never", "not now" and "remember".
    Remember stores the username/password. If another username exists, identical but with another case, then save it as case-insensitive, else save it as case-sensitive.

  - If there is a matching username/password and the username uses the same case as saved, but the password is different, ask the usual question:
      "Update saved password for user "xxx" on yyy?" with options "not now...

Read more...

Revision history for this message
In , Mozilla-e (mozilla-e) wrote :

The bug has been confirmed to exist in Firefox 5.0.

Both problems are still present.
- You cannot enter a username different from the first username you saved.
- You can however save the same username with a different case in the scenario displayed in comment 36. It cannot be used afterwards.

Revision history for this message
In , Mozilla-e (mozilla-e) wrote :

The bug still exists in Firefox 6.0.

Revision history for this message
In , Aimass (aimass) wrote :

Confirmed on Firefox 8.0.1 on Mac
I can't believe this is so hard to fix to take over 2 years! It seems a simple yet very annoying bug with no apparent workaround, except for firing up another browser and doing your thing there.

Revision history for this message
In , Mvel (mvel) wrote :

(In reply to Alejandro Imass from comment #39)
> Confirmed on Firefox 8.0.1 on Mac
> I can't believe this is so hard to fix to take over 2 years! It seems a
> simple yet very annoying bug with no apparent workaround, except for firing
> up another browser and doing your thing there.
You see, it's an opensource. When you fed up with particular bug, you ought to become a programmer, learn a project codebase and finally fix it :) But the thisParticularBugHatersCommunity.size() does not matter. So we should pray on Fx team and Google that supports them :)

Revision history for this message
In , Fche-p (fche-p) wrote :

This bug still exists in 9.*, and precludes logging on to different areas (authentication domains / URL prefixes) on the same web site with two differently-cased userids.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

*** Bug 727798 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Bugcuddler (bugcuddler) wrote :

*** Bug 742172 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Bugcuddler (bugcuddler) wrote :

*** Bug 605792 has been marked as a duplicate of this bug. ***

Revision history for this message
In , jidanni (dan-jacobson) wrote :

Still fully in bloom in FF 13.

Revision history for this message
In , Sgr33n (sgr33n) wrote :

This is a very annoying bug. Many websites uses case sensitive logins, Wordpress one of them. There's no way to insert a new login, even if you don't want to store it. I tried everyting :P The only way is to access to "saved passwords" menu and delete the wrong one.

Revision history for this message
In , Deletesoftware+moz (deletesoftware+moz) wrote :

*** Bug 512101 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Deletesoftware+moz (deletesoftware+moz) wrote :

*** Bug 787661 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Stajem (stajem) wrote :

Opened since 4 years ???
Completly agree with https://bugzilla.mozilla.org/show_bug.cgi?id=499649#c30

When can we hope a fix for this issue ? Many changes occurs on Firefox and it's a very good browser, but I don"t understand why an issue like this, can be still open 4 years...

Revision history for this message
In , D. Hugh Redelmeier (hugh-mimosa) wrote :

I'm using Firefox 22.0 on Fedora 19. I tried to log into a site typing a lowercase name. Auto completion offered both the lower case and initial caps version. But nothing I tried would let me get the lowercase name (tab, mouse click (on choices, or on other part of form), arrow key).

Jesse on #firefox suggested that I edit the saved passwords. I found that there was an entry for each casing. I deleted the initial caps version. Then all was well.

It seems odd to me that even though both spellings were in the table. I could only access one spelling.

Revision history for this message
In , Troy Sankey (sankeytm) wrote :

I'm having this problem too, but in my case there is *no user error*. I have multiple web services on that single domain, some with "Admin" and some with "admin" for technical reasons. This bug in Firefox is reproducible without user error.

Revision history for this message
In , Sslaks4 (sslaks4) wrote :

I am having this problem as well. I had both "myUser" and "myuser" saved in Firefox. My site actually has the username "myuser", but the other one was saved by mistake. When I login with user name "myuser", Firefox automatically changed the username to the saved username "myUser" in spite of having both saved!

This happens when I use tab to go to the password field (which most of us do I guess). When I use the mouse to manually go to the password field, it seems to work fine. Then I have to manually delete the entry "myUser" from Saved passwords and it works without issue. The browser cannot automatically assume the username since many sites let you create case sensitive login names.

Revision history for this message
In , Karl Fogel (kfogel) wrote :

For what it's worth, I too am having this bug, and likewise there is *no user error*.

We changed http://wiki.opensource.org/ from Dokuwiki to XWiki, and in the course of this change (I wasn't involved), the wiki superuser account name changed from "admin" to "Admin". But Firefox of course still remembers the old "admin" username, and force-downcases it when I attempt to log in as "Admin". There seems to be no gesture I can make at the form field that will cause it to simply leave alone the text I typed.

I eventually solved it by editing Saved Passwords to remove the "admin" record for that site, but that took a lot of menu-exploring to find, and I'm not sure I would have thought of it if I hadn't Googled up this bug ticket. While it is a workaround, it is certainly not a solution.

I hope it's not too strong a statement to say that any form field that *imposes* history, offering the user no way to type something and have the result be literally what they typed, is a buggy UI. When I typed "Admin" and saw the lower-case "admin" appear as the only item on a completion selection list right beneath the form field, I mistakenly thought that all I had to do was *not* select that completion. After all, if the UI is offering it to me and I am purposefully not choosing it, then that not-choosing is a gesture the UI should respect. But no matter how hard I tried, every time I left that form field, my carefully-typed "A" got changed to "a". That wasn't happy-making :-).

[This is Firefox (okay, Iceweasel) 17.0.9 on a Debian "testing" dist system up-to-date as of today.]

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

(In reply to Karl Fogel from comment #53)
> We changed http://wiki.opensource.org/ from Dokuwiki to XWiki, and in the
> course of this change (I wasn't involved), the wiki superuser account name
> changed from "admin" to "Admin". But Firefox of course still remembers the
> old "admin" username, and force-downcases it when I attempt to log in as
> "Admin". There seems to be no gesture I can make at the form field that
> will cause it to simply leave alone the text I typed.

You can type "Admin", and then click elsewhere to dismiss the autocomplete popup before submitting the form, right?

I just want to make sure I understand the scope of the issue completely. It seems like maybe the worst symptom of this bug could be addressed by avoiding having the Tab key auto-complete the saved value if it differs only in case from what's typed.

Revision history for this message
In , Lgrosenthal (lgrosenthal) wrote :

(In reply to :Gavin Sharp (email <email address hidden>) from comment #54)
> You can type "Admin", and then click elsewhere to dismiss the autocomplete
> popup before submitting the form, right?
>

No, Gavin. As soon as the password field is clicked, the username reverts to the saved case. Entering the password first, and then the "correct" username reverts to the saved username upon hitting the submit/login button. It's very frustrating. The only real workaround is as previously described: delete the existing saved password entry - or edit it. I've found that the Saved Passwords extension has become one of my best friends...

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

(In reply to Lewis Rosenthal from comment #55)
> (In reply to :Gavin Sharp (email <email address hidden>) from comment #54)
> > You can type "Admin", and then click elsewhere to dismiss the autocomplete
> > popup before submitting the form, right?
> >
>
> No, Gavin. As soon as the password field is clicked, the username reverts to
> the saved case.

I don't see this.

Here's what I did:
1) Load http://gavinsharp.com/tmp/form.html in Firefox (either Nightly or current release)
2) Enter "u" as username, and "p" as the password
3) Submit the form, and tell Firefox to remember the password
4) Reload the page (Firefox should now auto-fill in the saved password)
5) Replace the "u" in the username field with "U", and then click somewhere else on the page to dismiss the autocomplete popup
6) Submit the form (clicking the submit button)

Firefox then prompts me to save the new password for "U".

Revision history for this message
In , Pietro Battiston (toobaz) wrote :

Indeed, something has changed. I don't know if the bug can be considered as fixed, but it does seem to be mitigated under 24.1.0.

What, I think, is still annoying most of us (and the reason why I personally had not noticed the change) is that if you press "Tab" (which in principle does _not_ trigger autocompletion, i.e. if you just have just entered a prefix), Firefox does revert to the saved case.

Revision history for this message
In , Mozilla-e (mozilla-e) wrote :

I am pretty sure I have tried everything, including clicking out of the field, when I first got the problem. It was impossible.
But that was in version 5.0. I didn't retry every option with every new version.
I checked and indeed, it is now possible to save user 'User' with password 'p' and user 'user' with password 'ppp'.

Now how can I recall the password for user? If I press 'u' and select 'user' from the dropdown, it fills in 'User'. If I type 'user' and I tab out of the field, it gets converted to 'User'. In both cases the password is 'p'. If I type 'user' and click out of the field, it remains 'user' but there is no autocomplete.

The only thing you need to do to make me happy, and I am sure it is a small fix is:

When recalling the password, I imagine the code something like:
for each stored user/password {
  if( form user == stored user ignoring case ){
     set form user = stored user
     set form password = stored password
     break;
  }
}

The fix is to search first for an exact match, and if it fails, search for a match ignoring case
found = false;
for each stored user/password {
  if( form user == stored user ){
     set form password = stored password
     found = true;
     break;
  }
}
if( !found ){
  for each stored user/password {
    if( form user == stored user, ignoring case ){
      set form user = stored user
      set form password = stored password
      break;
    }
  }
}

I really don't know who can argue against this being a nicer behavior.

Revision history for this message
In , Mozilla-e (mozilla-e) wrote :

Version 26: bug still present.

Revision history for this message
In , Mathias Burén (mathias-buren) wrote :

Version 27: bug still present. Chrome 32.0.1700.72 beta-m handles this without issue.

As it is now, it's impossible to use Firefox's remember password function on a website which uses similar usernames differing only by case sensitivity.

Revision history for this message
In , Irgend-firefox (irgend-firefox) wrote :

I found the related line in the code: It's in LoginManagerContent.js at line 643. https://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/LoginManagerContent.jsm#643

It checks deliberately for the lowercase username. Last edit was by <email address hidden> on #839961 but this was just a refactoring. I don't know enough git blame to get the actual author.

Revision history for this message
In , Acraigwest (acraigwest) wrote :

This particular bug was introduced intentionally, as a fix for Bug#447788, which has a lot to do with why nothing has been done about it. The engineer responsible at the time was of the opinion that a web site with a case sensitive username was broken, so would not fix this. I may or may not agree, but I am very much of the opinion that it is not up to the browser to decide that, and as there ARE quite a number of web site's like this, the password manager should be able to deal with it.

Revision history for this message
In , Karl Fogel (kfogel) wrote :

A. Craig West's logic is spot-on. Whether or not the browser-side user approves of case-sensitive usernames, that user doesn't control whether *the site they're visiting* deals in case-sensitive usernames. The browser needs to be able to handle those sites too. Otherwise it's like saying because we're philosophically opposed to spammy pop-up windows, therefore we won't have features to deal with sites that launch them.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

(In reply to Florian Fischer from comment #58)
> Now how can I recall the password for user? If I press 'u' and select
> 'user' from the dropdown, it fills in 'User'. If I type 'user' and I tab
> out of the field, it gets converted to 'User'. In both cases the password
> is 'p'. If I type 'user' and click out of the field, it remains 'user' but
> there is no autocomplete.

This is correct - no way to autofill both versions, and the autofilling sometimes gets you the wrong thing. This we can fix easily enough.

This bug has nothing to do with Firefox developers deciding we hate case-sensitive passwords - you can read the entire rationale in bug 447788. Some sites were "broken" before that change, and that change fixed them. Now other sites are broken, and we should fix those too.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

Created attachment 8381156
patch

Summary of changes:
- add a "userTriggered" parameter to _fillForm to distinguish the onFormPassword and nsILoginManager::fillForm callers from the onUsernameInput caller
- when filling any form, if there are multiple signons that match but one's username matches case exactly, prefer it
- when filling in a form whose autocomplete was "user triggered", i.e. triggered by focus changes or a DOMAutoComplete event, don't clobber the username field value if it differs only in case (this is to handle the case where you've saved "USER:pass" but want to manually fill in "user:pass" and don't want your entered username from being clobbered when the password is filled in). This essentially undoes bug 447788, but only for the user-interaction case, not form filling on load. It might lead to confusion in the opposite direction, if the site is case-sensitive, but users manually enter the username with the wrong case (without selecting the autocomplete) and then have the password auto-filled, and then submit the form. I think that's a relatively unlikely scenario compared to the one this addresses, so the tradeoff seems acceptable.

There's a confusing twist on that last point: in the case where you explicitly select an autocomplete entry (i.e. via "Enter" or clicking the popup), nsAutoCompleteController::EnterMatch sets the input field's value before calling OnTextEntered (which fires DOMAutoComplete), so we don't hit this new case in _fillForm (usernameField.value is exactly equal to selectedLogin.username). So the behavior from that last point only really applies to focus changes (i.e. tabbing away from the field) in practice.

I copied the test, but there's so much removed, it's probably easier to just review the new file on its own. Confirmed that I added test coverage for both changes.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :
Revision history for this message
In , Acraigwest (acraigwest) wrote :

(In reply to :Gavin Sharp (email <email address hidden>) from comment #64)

> This bug has nothing to do with Firefox developers deciding we hate
> case-sensitive passwords - you can read the entire rationale in bug 447788.
> Some sites were "broken" before that change, and that change fixed them. Now
> other sites are broken, and we should fix those too.

First, I want to say that I am very happy that Gavin fixed this :-)
My comment about developers hating case-sensitive passwords was actually in reference to bug 47594, which this one is technically a duplicate of. In Comment #2, as he was marking the bug WONTFIX, Justin said:
> This is probably partially a result of the fix for bug 447788.
>
> We're kind of screwed no matter which way we do things, but I think the
> current behavior is better. Having multiple accounts (with different
> passwords) that differ only in case is already full of fail for a multitude
> of reasons, so I'm not really inclined to want to support that use-case.

Admittedly, once THIS bug got opened, the discussion was much more positive... (Come to think of it, that appears to have largely been due to Gavin's influence as well :-) )

Changed in firefox:
status: Confirmed → In Progress
Revision history for this message
In , Mattn+bmo (mattn+bmo) wrote :

*** Bug 923939 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :
Revision history for this message
In , Philringnalda (philringnalda) wrote :

Followup in https://hg.mozilla.org/integration/fx-team/rev/d2059cb5dbf4 to skip the test on Android, since it fails just like the skip-ifed source it was copied from fails.

Revision history for this message
In , Ttaubert (ttaubert) wrote :
Changed in firefox:
status: In Progress → Fix Released
Revision history for this message
In , Octoploid (octoploid) wrote :

There are debugging dump statements left in this patch,
that print the username on every auto-login attempt to the console.
This might be a security issue, because it is now easy to tell when
and under what username a user tried to login to varies websites.

Revision history for this message
In , Dolske (dolske) wrote :

Whoops. I pushed https://hg.mozilla.org/integration/fx-team/rev/1696574aa611 to remove the dump()s.

Not a security issue.

Revision history for this message
In , Ttaubert (ttaubert) wrote :
Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

Embarassing! Thanks for catching that.

Revision history for this message
In , Mattn+bmo (mattn+bmo) wrote :

*** Bug 523899 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Mattn+bmo (mattn+bmo) wrote :

*** Bug 516037 has been marked as a duplicate of this bug. ***

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.