User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.6) Gecko/20040206 Firefox/0.8 Fourmix is an online game, with a forum. Game is here, with a classical login form : http://merome.net/fourmix Forum is here, it's phpBB2, with its specific authentification form : http://merome.net/fourmix/phpBB2 FireFox 0.8, as FireBird 0.7 only remember one login/password : the first that has been stored in password manager. FireBird 0.6.1 did the job, remembering both game and forum login/password. It seems to be a regression of the "new" password manager (FB 0.7). Note that for another game, with a third login form at http://merome.net/wargang ,the login/pass is remembered. My guess is the l/p are not remembered when on a subsite of another stored l/p. Reproducible: Always Steps to Reproduce: 1. Create a game account on http://merome.net/fourmix (it's free !) 2. Create a forum account on http://merome.net/fourmix/phpBB2 3. Try to login to the game and then to the forum Actual Results: Only the first login/password stored is remembered. Fields are leaved blank on the second form. Expected Results: All login/password should be remembered, as FireBird 0.6.1 did. Note that I'm using localized (french official) version of FireFox. Creating a new profile does not resolve the problem on 0.7 (not tested on 0.8).

--> Confirmed --> Major since this is a usability issue that I'm surprised has surfaced before Created two logins for testing: http://merome.net/fourmix/ firefox1:test1 http://merome.net/fourmix/phpBB2/login.php firefox2:test2 I get the issue with respect to the second site regardless of logging into the former. The login appears in the autocomplete dropdown, but that is all. It doesn't fill the password field when selected. With a separate profile and testing *only* the second login password manager works as expected, filling out both fields. Merome: can you try removing any uses of value="" in your forms and see if that makes any difference?

There is no use of value="" in these forms. They are pretty simple, as you can see : http://merome.net/fourmix Login : <input type="text" name="login" size="20"> Password : <input type="password" name="password" size="20"> http://merome.net/fourmix/phpBB2 Login : <input class="post" type="text" name="username" size="10" /> Password : <input class="post" type="password" name="password" size="10" /> And no javascript, or special things like this, filling or emptying automatically the fields : two very basic forms. It should be interessant to try to reproduce the bug with two simple forms on two pages placed as mentionned above : one on a site and another on a subsite of the first, for example : http://www.mozilla.org/form1.htm http://www.mozilla.org/subsite/form2.htm I'll try to make these simples pages on my own website, but it could be more convincing if someone else can do it on a another place.

hello, I'm also quite disapointed with the password manager's new behaviour ... with former FireBird, when arriving on a page with several login/passwords saved for it, a list box would pop up and prompt to choose one login/passwords. This no longer happens ! You have to remember the logins that are recorded for the page, enter one of them manually, tab, and ONLY THEN the appropriate password appears in its text field ! Annoying and time consuming ...

Re: comment #3 -- Often enough, that doesn't even seem to work (i.e., type in the username, but *no* password appears). In fact, password *and* forms behavior is generally inconsistent across the board. In some cases the same form doesn't always behave (or misbehave) in the same way (e.g., my eBay login). This, of course, makes it very difficult to file a bug.

We should not be confused by : - several login/pass on *different* pages of a site are not remembered at all (this bug) and - several login/pass on a *SAME* page are not remembered without keyboard action (other bug or enhancement) Comment #3 From William should not be here, IMHO.

(In reply to comment #5) > - several login/pass on a *SAME* page are not remembered without keyboard action > (other bug or enhancement) > Comment #3 From William should not be here, IMHO. Well I am trying to login to an Exchange email server with two different usernames and the password manager can no longer remember the 1st username/password (adding the 2nd one kicked out the original).

bryner, what are the odds of getting some sort of fix for this done for 0.9?

Not going to block the release for this. It would be nice to get but with limited resources, we've got to make the cut somewhere and this seems like a niche case.

-ing since it's an edge case. would consider patch.

Bug still present in 0.9. Affects me with www.minigallery.co.uk where I have logins on both the main site and a subsite (/forum) which differ. The first is user name mike.finley@xxxx.yyyy (a private email address) the second is user mike The password is saved correctly for the latter (probably the first I logged into with firefox), not the former.

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

This is a BIG problem. Our students log into the main site with one user/pass pair, then have to log into parts of the site with a different user/password pair (please don't ask why...). Firefox and Mozilla reject the login to the lower level. So the site is useless if you use FF or MOZ. (Mac Safari and Internet Explorer work correctly, btw).

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

This function worked great in Mozilla, why not FireFox? Very time consuming for multiple secure pages from a single site.

OK, I tested with two pages on my localhost: http://localhost/phpMyAdmin/ - phpMyAdmin http://localhost/com/php/ - development copy of my own site system Both Firefox and SeaMonkey (i.e. new and old password manager) correctly remember different usernames (and passwords) for those two different paths on the same domain (and port). The big difference I see between the login situation of the pages in comment 0 and mine is that in comment 0, both relevant login forms have no name attribute (i.e. the same internal form name), but in my case, phpMyAdmin has <form name="login_form"> and my system has <form name="loginform"> (i.e. different internal form names). From that, I suspect that we're saving the form name along with the user name and only fill in to the "correct" for name. To prove that, I added an additional <form name="login_form"> to a page in my system - and it gets the phpMyAdmin username and password prefilled by Firefox (and Seamonkey as well). If the <form name="loginform"> and <form name="login_form"> are now shown on the same page, each of them gets the username/password for their respective form name prefilled. So, here's my conclusion: 1) I see no regression, it works the same for both old and new pwdmgr 2) It's open for discussion if that's a bug or a feature, I actually think it's the latter. We do the correct thing with respect to the form name. If a bigger site displays login forms with the same name across different paths one would expect to be able to login to the same system for all of them with the same username and password and to have the browser prefill that. 3) On could argue that we should do some sort of a workaround solution for badly designed sites as that in comment 0, i.e. if there is no form name/id set, and use the path name instead in those (and only those) cases.

I'd this is a bug. Passwordmgr should respect different paths, which it doesn't seem to do currently. Also, what if the form name isn't specified? Then we probably do the wrong thing.

Mass edit: Changing QA to default QA Contact

Testing shows: 1. The second site always works correctly. 2. The first site does not automatically fill in the login. However, pressing the down key does show the autocomplete popup correctly and choosing firefox1 does fill in the password correctly. Will have to investigate further. Note that the test sites *do* have the name attribute specified correctly in the input elements.

The issue here is that we're inadvertently also checking for signons with the same password field before deciding not to fill in the password. As long as the password field is found, the code falls through and counts the signon as another valid one even if the username fields don't match. This patch makes sure that we bail out if there is a specific username field requested and we don't find it.

mozilla/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 1.85

We are a little nervous about messing with form field matching at this point. Can we get a set of positive/negative regression testcases added so we can be sure that we haven't accidently broke something. CCing RobCC and DaveL in case they can help...

We can't null out userField. Bad idea. This patch uses the correct way to check if we found a username field for this particular signon.

This testcase has four forms. The first two have different username field names, but same password field names. The last two have different password field names, but same username field names. If you save a single login/password for each of these forms, each one should fill its own signon when loading the page again.

Ok, I've given up hope for this making branch. Bug 235336 caused regressions which really confuse my efforts to really get this right.

mozilla/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 1.86