366920 - Had duplicate password entries, tried to delete the bad one and it deleted the good one instead.

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect)

Description

[Dave Miller [:justdave]]

I have no idea what my bank site did to cause Firefox to store two passwords for the same username at the same URL, but it did.  I had two entries for my bank site in the password manager for the same username.  one of them had the correct password, one of them had my old password before the last time I changed it.  Just trying to do a little housecleaning, I tried to delete the old one by highlighting it and clicking the Remove button at the bottom.  It went away, leaving only the new one visible on the screen.  But next time I went to log into the bank site, it won't fill the password in at all (maybe this has something to do with why it duplicated it?).  So I go back to the password manager and look, and the entry with the incorrect password is still there, and the one with the correct password is gone.

Thank God for profile backups. :)

Comment 1

[Dave Miller [:justdave]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Did you deleted it from the password manager, or from the autocomplete dropdown?

Comment 3

[Dave Miller [:justdave]]

From the password manager.  I've never gotten the delete from the autocomplete dropdown to work on OS X.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Could this be a dupe of bug 343738?

Comment 5

[Dave Miller [:justdave]]

(In reply to comment #4)
> Could this be a dupe of bug 343738?

I doubt it.  This wasn't a multiple-select situation.  I only had one item selected, and it deleted a different item than the one I selected (probably using two of the columns as a key and not all three of them or a tree position)

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Well, I doubt that bug is specific to the situation it's comment 0 describes. The tree selection/deletion code is busted in other ways, I think, which could probably cause this bug. I'll mark depends for now, but without steps to reproduce it's going to be kind of hard to make any progress on this bug.

Comment 7

[Dave Miller [:justdave]]

I suspect they probably changed the name of one of the fields in the password dialog or something to cause it to duplicate the entry.

Comment 8

[Phil Ringnalda (:philor)]

It's not actually surprising that the wrong one was deleted: the deletion happens by FinalizeSignonDeletions calling removeUser with just a host and username, because the combination of just those two things is supposed to be unique, and because new signons are saved at the start of the list for a particular host, the newer one, and the one that you were using, would have been the first match for that host/username found.

Unless I'm missing something, the bug is that you got to save a second one: a change in field name wouldn't matter, because all of the checks for existing signons pass in a blank field name, but any failure in the process of looking for an existing signon looks like it will be treated as successfully finding that there is no existing one.

Comment 9

[Justin Dolske [:Dolske]]

This should be fixed with the new password manager.

FinalizeSignonDeletions(), in toolkit/components/passwordmgr/content/passwordManager.js, now calls removeLogin() with the nsILoginInfo object originally obtained from getAllLogins(), and a stricter comparison is done.

Comment 10

[Justin Dolske [:Dolske]]

Oops, meant to close this.