See bug 85777 which should not have been closed. That was a bug misfiled on tech evangelism that points to a real problem in the Mozilla and Netscape browser's password management funtionality. This is the bug to make password manager not suck when visiting mozillazine.org, devtrack, doctor (the new webtool for making changes to the mozilla.org website) and other sites which don't conform to the not very smart heuristic that we currently use to identify the fields that should be remembered.

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

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

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

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

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

Related: bug 124070, Password Manager records duplicate identical logins at mozillazine.

I hope this time somebody decides to do something about improving the heuristic, instead of just brushing it off with a "WontFix" like before...

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

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

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

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

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

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

Another example of a site where the current implementation goes nuts is the forums site at http://forums.battle.net/ There are three form fields relevant to this example. The user name, the password, and the subject of the post. Current behavior: Every user/pass combination with a different subject is stored as a separate login (all three fields are stored). Expected/Sensible Behavior: Every user/pass combination should only be stored once regardless of other form fields. First of all, the subject of the post has nothing to do with login information, so it shouldn't be stored in the first place. If the intent was really to store all relevant data in a meaningful way, user/pass/subject triplets should be shown in the password manager identified with both user and subject, not just user. Otherwise, there will be many entries with the same user, with nothing to differentiate them. Admittedly this may be hard to do, especially if a web page designer (maliciously or otherwise) designs a form where the user name and password fields are out of order, are separated by other fields, are given unusual names, or are otherwise obfuscated. Nonetheless, the current implementation is not acceptable. Either only store the fields relevant to login information (which would be preferrable), or at least differentiate the entries in the login chooser by showing all non-password fields. This would at least get rid of the problem of seeing 10 entries for "JoeUser" without anything to distinguish one from another.

Reassigning to new module owner

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

I was the submitter of bug 200653, and I wonder if one thing I did may lead to a potential workaround. Specifically, I hacked the wallet file to remove the entry for TITLE, leaving username and password. This, however, leads Password Manager to ask me if I want to save the relevant info every time I post there. I do not wish to choose "Never for this site" in response to that question, as my intuitive belief is that that would remove the info I have already stored. My question is, for the case where some form info was available to be entered, and was submitted unchanged, could PM exhibit one of the following behaviors: 1. Do not prompt the user at all, or 2. Prompt the user, but make a fourth choice available which would have the effect of "Do not ask me this again for this site, but keep using the info I have already stored." This choice could be on the dialog but inactive when the above criteria are not met by the form submission.

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

In the past, i created a fake post on mozillazine where i left the "Title" blank, then allowed PM to store the info. Then on my second post, I selected never store PW from this site. This had the neat effect that the first info was retained (and autofilled), but subsequent entries (with a Title) were not added to the PM list. For some unknown reason, the ability to say "Never store PW's from this site" was removed from mozilla (although the tab in PM still exists. Suggestions: 1. restore the ability to say "Never store PW's from this site", or 2. if a site has ONLY clearly identifiable UN and PW fields, store the info. 3. IF there are more fields, bring up a dialoge: +-Password Manager ----------------+ | Store login info for this site? | | [x] UN [ ] | <-- default: ON | [x] PW [ ] | <-- default: ON | [ ] Subject [ ] | <-- default: OFF | [ ] etc. [ ] | <-- default: OFF | [ OK ] [ Cancel ] | +----------------------------------+ Note: Adding to summary to avoid more dupes (apologies, if unwanted)

It is know that the password manager heuristic can fail, but it is hard to come up with a better heuristic. If anyone knows one, please explain it. It doesn't need to be actual code, pseudo-code will do :) A huge, complicated UI won't be acceptable. Neither will detecting the name of the text fields. That will break on sites not in english. For the record, what i understand of the code, wallet currently looks for a form field of type password, and then takes the first text field of the form to be the username. It does some other stuff, but that is not really understandable.

re comment #20: i do not understand, why this heuristic would save multiple userid/password entries (but with identical userid/password) for the mozillazine main page forums. When I go to preferences/privacy/passwords/manage.. several identical lines are shown. Now the odd thing is that if I select different entries from all those that look identical, the "Title" field of the form gets filled in with different values. So obviously, the password manager not only stores userid and password, but also the title, and since that is different for different posts, I get multiple entries. The thing to do in that case seems to be to just ignore anything but the first two fields. I think a better heuristic would be to find the first field that is a password (invisible) field, then take the one preceding that field (not the first one) in the same form - unless the password field is itself the first field, in that case take the field after the password field. And take only these two :) What is the idea behind remembering more than userid and password anyways?

Johann - you're assuming that Mozilla knows which field is which. All it has is the field types. Mozillazine, for example, looks something like to Mozilla: field1 (text) field2 (text) field3 (password-text) field4 (textarea) Mozilla doesn't know which fields are log in information and which fields are not - it only knows the type of the field, not the content. AIUI, the current code stores everything that's not a textarea. The problem is how Mozilla can work out which fields are username and password and which fields are something else, given that the fields could be named anything (and in any language).

I do not think I was assuming that - I thought that is what we need a heuristic for. Saving everything that is not a textarea is not a heuristic. Comment #20 indicated a heuristic that I think could be improved. Your comment indicates that such a heuristic is not used. Anyways - any heuristic will fail, the question is, are there heuristics that will fail less often? And can we work out something so that web site programmers can "help" mozilla to get it right without giving up too much flexibility? As I said in my previous post: there might be possibilities for heuristics like: UserID and password usually come one after the other (ignore checkboxes etc). UserID usually come before password. Usually there is only one password field. Even the "name" heuristic could be added - even if it fails for other languages, it might improve the overall rate of getting it right, if there are ambigous situations. If password manager really saves *all* fields in the form, there is another way to fix bad or erroneous behavior: add a dialog in the preferences/manage password section that shows the list of fields stored and let the user check the two fields that are really important. Then at least, the user has an option to correct the bad behavior a-posteriori which is impossible now: either I live with multiple entries or I have to disable that feature for the site alltogether.

As an afterthought, it might be good to at least *allow* page authors to give Mozilla a hint which fields to store and which to ignore. For example, there could be two names that will always be recognized as password and userid ( maybe something like "MozRememberedPassword" and "MozRememberedUser". The damage in the extremely rare case somebody wants to use these for something else is very small, and the benefit for those who need to create forms with more than just those two fields high. Obviously this is really something that should besolved thought an additional attribute for the input tag in the W3 spec though.

The tendency is for bulletin board sites to use: field1 (text) [ username ] field2 (password-text) [ password ] field3 (text) [ subject ] field[4..n] (text or textarea) [ other stuff ] One simple heuristic that would work on most sites I use is to just ignore anything after the password field.

Suggested heuristic: - Make a list of known sensical field-names ("name", "password") in many languages (DE: name, passwort) that are almost certain to yield a "hit" for most sites. (To confirm the PW, also check for a PW-text field, so we don't splash the users' PW onto the screen into a readable field.) - If none of these work, THEN use the (ill)logic we have now. After all, this is the PASSWORD manager (so UN & PW should suffice) and not the FORM manager. (i've never really fully understood the way our form manger works) Don't remember the subject (etc) in the PASSWORD manager.

That won't work. The list would be huge. And even then, it will miss lots of cases. like 'id' for the username. So footprint will increase a lot, without much gain. I don't need translations and variations of "username" in all kind of languages i can't read. And for my native language, dutch, it will fail in lots of cases. I can come up with lots of names for the username field, which will not be in that list. It will be much better to create a better general heuristic. The suggestion in comment 21 makes sense to me. It is easy to find the password (type=password), and then look at the closest normal input field. (afaik, firebird currently uses this)

I still thing that looking for the 2-10 most likely candidates will most accurately catch a majority of the sites. If that simple check fails, we can then still use "heuristics" (witches brew). HTML code is always in english. I bet many site developers could easily adapt to using mozilla's standard terms (without even knowing it). My list: username user name user user ID user-id userid ID password pw

a quick list of the names of the username and the password fields from a few sites i log in to: sieveuid, passwd pma_username, pma_password Bugzilla_login, Bugzilla_password S19_, S33_ All of those fail the list, and would pass the 'search password, username is the field just before it' algorithm.

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

Perhaps Mozilla could ask you(for sites with multiple login stuff) which parts to keep(displaying the text of each) and then give you an option to stop it from asking you for more passwords to this site.

A nice solution (for website authors) would be to use autocomplete=off on those fields which shouldn't be stored, like "title" on mozillazine talkback. But that doesn't seem to work: autocomplete=off has to be either on the form itself, or on the password input field.

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

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

I've been trying Opera 7.5p3 for about a week, and its "wand" feature for remembering logins and passwords is great. It works on all kinds of sites that Mozilla's password manager doesn't handle well, including MozillaZine talkback, the Charles Schwab Customer Login, and Schwab BillPay. Any chance we could reverse engineer Opera's heuristics?

Another site with this problem: https://ssl.galileo-press.de/login/ the login-name and the passowrd-field will not be found. I hope, they fix the code (72 errors). Greetings, Markus

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

Here's another situation where PM fails. When you have multiple Mailman lists that you're managing, it only remembers the password for the last list you managed. You log in to Mailman list management at a page like this: http://your.domain.ext/mailman/admin/listname_domain.ext/ where all the lists on a given domain have identical URLs except for "listname".

WONTFIX based on the fact that we have thrown the old wallet password manager out the door on SeaMonkey 2 development replaced with the same password manager backend as Firefox, see bug 390025. Yes, we now have bug 222589 in SeaMonkey 2.0a3 and later, but with the now much smaller volunteer team we just can't take up our own development of things like password manager.

Robert, we should at least name an open bug here which will make sure that we get this multi-dupe bug solved. Fine if this is part of Firefox and available in SeaMonkey. I suggest to reopen and dupe it to that bug. Thanks!