436275 - wrong password filled in when same login is used for different forms (with different form fields names) within one site

Status: RESOLVED WONTFIX

(Toolkit :: Password Manager, defect)

Description

[Tomasz Pala]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9) Gecko/2008051202 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9) Gecko/2008051202 Firefox/3.0

At first - it looks like a duplicate of <span class="bz_closed"><a href="show_bug.cgi?id=263387" title="RESOLVED WONTFIX - passwords should be stored for host+path and not just host">bug 263387</a></span>, but it is not. It refers to different form fields not path, however the effect is similar.

According to <a href="http://kb.mozillazine.org/Signons3.txt">signons3.txt description</a> there is a place for HTML user name and password fields. I've got two different services and my signons3.txt contains:

---
.
https://my.site
loginUsername
[encrypted login]
*loginPassword
[encrypted pass]
https://my.site
---
stqser
[encrypted login]
*spass
[encrypted pass]
https://my.site
---

Now when I try to login to either of services FF 3.0 (tried b5 and rc1) fills in the first password regardless name of form field. I didn't have this problem in 1.5 or 2.0 series - passwords were not mixed. I've just checked on 2.0.0.13 and it works as expected - password filled in is the one connected with actual login (connected via fields names) according to signons2.txt. Moreover - in 2.0 password manager doesn't even suggest login which 'belongs' to other login field name, but in 3.0 breakage I have to choose from all the logins remembered for a site.
In conclusion: pre-3.0 password manager used both site name and form fields names and it was good. 3.0 password manager looks ONLY at site name, which is bad and makes 2 lines of signons3.txt file completely needless.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Justin Dolske [:Dolske]]

Form field names are not used any more, but if you have 2 logins that are only differ in username/password, then it generally shouldn't be autofilling anything (although there are exceptions).

Enable debugging per http://wiki.mozilla.org/Firefox:Password_Manager_Debugging, and paste the output from loading the page here? Also a snippet of the form HTML from the login page?

Comment 2

[Tomasz Pala]

> Form field names are not used any more,

How can I bring it back? Or could you point me out some add-on or piece of code that has been changed so I can revert the change and rebuild FF for myself?

I've got even more than 2 logins that differ in password only. Opening a page:

Login Manager: onStateChange accepted: req = https://XXX/X.php, flags = 0x30004
Login Manager: domEventListener: got event DOMContentLoaded
Login Manager: Counting logins matching host: https://XXX, formSubmitURL: , httpRealm: null
Login Manager: fillDocument processing 1 forms on https://XXX/X.php
Login Manager: Searching for logins matching host: https://XXX, formSubmitURL: https://XXX, httpRealm: null
Login Manager: form[0]: found 5 matching logins.
Login Manager: attaching autocomplete stuff
Login Manager: Multiple logins for form, so not filling any.

choosing one of the logins from list containing 5 entries (4 of them are 'gotar' as imported from signons2.txt from FF 2.0):

Login Manager: AutoCompleteSearch invoked. Search is: 
Login Manager: Creating new autocomplete search result.
Login Manager: Searching for logins matching host: https://XXX, formSubmitURL: https://XXX, httpRealm: null
Login Manager: 5 autocomplete logins avail.
Login Manager: domEventListener: got event DOMAutoComplete
Login Manager: fillPassword autocomplete username: gotar
Login Manager: Searching for logins matching host: https://XXX, formSubmitURL: https://XXX, httpRealm: null
Login Manager: Found a matching login, filling in password.
Login Manager: domEventListener: got event blur
Login Manager: fillPassword autocomplete username: gotar
Login Manager: Searching for logins matching host: https://XXX, formSubmitURL: https://XXX, httpRealm: null
Login Manager: Found a matching login, filling in password.

And of course the password filled in is incorrect - this particular one was remembered for loginUsername and *loginPassword, while the page I've opened has stqser and *spass (stripped non-form elements):

<form action='?act=login' method='POST'>
<input type='submit' value='Login:'/>
<input name='stqser'/>
<input name='spass' type='password'/>
</form>

After I've cleaned these 5 passwords from password manager, FF3 saves only one per site-login, so any time I've got only 1 pass instead of 4 saved. It's pretty annoying to type-in password every time I want to use different service on this site.

Comment 3

[Tomasz Pala]

According to:
http://wiki.mozilla.org/Firefox:3.0_Password_Manager#Robustness_to_Site_Changes
FF3 should use field names. What's rationale in not using them anyway?

Comment 4

[Justin Dolske [:Dolske]]

(In reply to comment #2)

> I've got even more than 2 logins that differ in password only.

Multiple logins with the same username but different passwords are not supported.

This is WONTFIX, because this use case is exceptionally uncommon. Fixing this would cause problems with the normal use case, where people are changing their password (or enter a wrong password) for an account, and we don't want to save all those as multiple logins.

Comment 5

[Tomasz Pala]

(In reply to comment #4)

Apparently you didn't read or don't understand.

> This is WONTFIX, because this use case is exceptionally uncommon.

1. it's not about different passwords with same login only. Consider:

FORM A - user joe
FORM B - user henry

and I repeat - different FORM on same site, not URL. FF 2.x did the right thing autofilling these names according to form fields names, while 3.0 pops up both logins on both forms. And it's obvious for me, that field names in signonsX.txt are for some reason, not for decoration.

> Fixing this would cause problems with the normal use case,

Yep, you didn't read - are you saying that all FF 2.x users have problems now? Because, let me repeat, that is the way current FF behaves. And it works well.

> where people are changing their
> password (or enter a wrong password) for an account, and we don't want to save
> all those as multiple logins.

Yep, you don't understand at all... If I change or mistype a password for a SINGLE FORM, SINGLE pass was saved. We are talking here about different FORM FIELDS NAMES. Have a look at signonsX.txt file format and justify 2 lines containing them.

Anyway I've resolved this problem by switching to Seamonkey. It's not broken and it's fast.

Comment 6

[Tomasz Pala]

Attachment: POF patch for FF 3.0.x

Just for the record, as I've resolved this on my own. This patch probably isn't complete, but it works for me and could be a good point for anyone having this problem.

Comment 7

[Tomasz Pala]

Attachment: POF patch for FF 3.5

Previous patch adapted to SQLite storage used in FF 3.5. Again - it's just prove of concept, but it's useful for me, so I share.

Comment 8

[Tomasz Pala]

I forgot to mention the most important part: these can be applied to compiled and installed version, and reverted the same simple way, as they alter only some js code. That's why findLogins function in storages splits hostname from usernameField passed as single argument.
So in short: anyone can patch and revert in place (e.g. if some extensions broke).

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

Justin, would you be willing to revisit your decision wrt. this bug? It seems that reporter is referring to combination of url+formname which should not carry the risk you were writing about in your previous comment.

The patch needs some cleanups, but it seems that Tomasz, with a little bit of feedback, can work on it.

Comment 10

[Justin Dolske [:Dolske]]

Not really, making the password manager rely on field names isn't something I want to do.

Comment 11

[Tomasz Pala]

Attachment: POF patch for Fx 3.6

For all those people ignored by devs, having multiple login/pass pairs within single host, exposed to senseless, illogical and misleading credentials autocompletion; updated patch allows you to both, supress redundant login hints (not appropriate for current form) and save different passwords for same login (with regard for opened form) comfortably.

Comment 12

[Daniel Marschall]

I have exactly the same problem. Different forms at different URLs store the passwords wrong because they change each other password. Usernames are also different.

Now, I am enforced to change all behavior of my PHP websites and rewrite URLs to different VirtualHosts just make it work for FF users.

It is a shame that developers ignore this issue. And this is one reason, why I stop using Firefox and change to browser manufactures who care about feedback.