User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1) Gecko/20090616 Firefox/3.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1) Gecko/20090616 Firefox/3.5 If you try to log in to a site that uses case sensitive usernames and accidentally has Firefox remember a username with wrong case there is no way to log in anymore without deleting the saved username/pass. Reproducible: Always Steps to Reproduce: 1. Go to http://www.inluppar.com/logintest/ 2. Enter username "user" and password "pass" and press "Log in" 3. You will get an error saying login failed but save password anyway 4. Go back and try to login with username "User" and password "pass" Actual Results: Username is changed to "user" and login fails and there is no way to login while the incorrect username is saved Expected Results: Firefox should accept the case-altered username and send that instead. This affects branch and trunk, but not 3.0.*

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...

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.

(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.

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.

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.

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.

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

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.

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).

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.

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.

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.

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.

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

> 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.

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?

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.

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!

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 !

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.

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" and "update". Update replaces the password in the saved username/password entry. - If there is a matching username/password and the username uses a different case and a different password than saved ask: "Replace saved username and password for user "xxx" on yyy?" with options "not now", "replace" and "remember both (case insensitive)". Replace replaces the username and password in the saved username/password entry. Remember both (case insensitive) creates a new entry and marks both entries as case-sensitive. Note: here, "xxx" is the saved username. Password manager. - The case-sensitive flag should be visible in the password manager. It should be possible to set it (make it case-insensitive) but only after deleting duplicates. - There is no other way to revert to "case-insensitive", as it involves removing saved username/password entries. Summary The saving of passwords remains case-insensitive as long as no conflict occurs. If the user uses different accounts with different cases, but still with the same password, then saving a single password with a case-insensitive username is still appropriate. Only when trying to set a different password for a different username case will FF ask how to treat case-sensitivity. One thing that is still missing is the possibility to change the case of a username that was saved wrongly. The problem being that it will auto-fill with the wrong case. For that, the last case ("replace?") should also be triggered when the user submits a form, and the username was auto-filled from the saved usernames, but the user changed the case manually. I don't know if that logic can be implemented in a simple way. Best regards, Florian Fischer

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.

The bug still exists in Firefox 6.0.

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.

(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 :)

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.

Still fully in bloom in FF 13.

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.

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...

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.

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.

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.

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.]

(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.

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) 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...

(In reply to Lewis Rosenthal from comment #55) > (In reply to :Gavin Sharp (email gavin@gavinsharp.com) 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".

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.

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.

Version 26: bug still present.

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.

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 dolske@mozilla.com on #839961 but this was just a refactoring. I don't know enough git blame to get the actual author.

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.

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.

(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.

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.

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) 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 :-) )

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.

https://hg.mozilla.org/mozilla-central/rev/8ecbb7a38b29 https://hg.mozilla.org/mozilla-central/rev/d2059cb5dbf4

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.

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

Embarassing! Thanks for catching that.