Closed
Bug 315416
Opened 20 years ago
Closed 18 years ago
Passwords reappear after being deleted, some can never be deleted
Categories
(Toolkit :: Password Manager, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: mbrownah, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
The same corporate password works on many internal webservers. The password has to be changed regularly, and then each instance of the password needs to be changed. I did a 'show passwords' to see which websites still had my old password and removed all that had old passwords. After closing the dialog box, and the 'Options' window, and then re-opening them, I found that all those websites were back in the window. Removing some of them a second time permanently removed them, but other passwords are unable to be permanently removed, no matter how many time I remove them. They reappear the next time I bring the password manager dialog box up.
Reproducible: Sometimes
Steps to Reproduce:
1. Open Password manager (Options, Saved Passwords, View Saved Passwords'
2. Select and Remove a website login line
3. Close Password manager dialog box and Options dialog box
4. Reopen Options and 'View Saved Passwords'
Actual Results:
Some password lines won't be removed, some seem to never be able to be removed.
Sometimes duplicate entries will exist - same URL, but with a different title in the "()" - perhaps when the web page title has changed. Removing both entries will still not remove the bad entry permanently.
Expected Results:
Password lines should be removed permanently when the 'Remove' button is hit.
Related to bug 312922 or bug 269353?
My problem does in fact seem to match the descriptions in both of these bugs (didn't see them during my bugzilla search). I did not receive any Exception as described in bug 269353, however I did find that all of the problem sites have a port number in the URL (:80). It turns out that all our corporate sites seem to have a port number attached - I suppose it is some option in the DNS server. Either way, it is possible for the existence of the port number to be related to the root cause of the issue.
Comment 3•18 years ago
|
||
Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!
Whiteboard: CLOSEME 06/27
Version: unspecified → 1.0 Branch
With no response from the reporter, this bug will be resolved WORKSFORME on June 27th.
Comment 5•18 years ago
|
||
No response from reporter re: comment 3, and this wfm -->WORKSFORME.
Reporter, if you still see this problem with the latest release of Firefox 2, please reopen this bug. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Sorry, I was on vacation for 2 weeks and didn't have time to test this before I left :)
I upgraded to Firefox 2.0.0.4. I can reproduce the problem the same as before - it is not fixed in this version.
One thing nice about this version (I don't remember if this existed in v1.5) is that after doing 'show passwords' I can sort by password, and group all the corporate passwords together, then delete them all quickly. Unfortunately, when I close the dialog box and reopen them, most of them remain. Repeating this procedure occasionally will remove one or two of them, but I can never remove several of them.
Again, the ones that seem impossible to delete have a port number attached to the URL (e.g. ':80') For the ones that don't get deleted at first, but get deleted on subsequent tries, I theorize that once the delete operation breaks on one of the URL's with a port number, the URLs that are in the list later are skipped on that operation but delete properly later if I select them individually, or perhaps the delete order is changed due to the previous delete operation.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 7•18 years ago
|
||
Hmm, it would be helpful to verify the problem if you could supply a reproducible, reduced testcase for this... Logins are stored in the signons2.txt file in your Firefox profile. Backup this file, and then delete it from your profile. Then add just enough entries such that you can recreate the problem. You can censor the encrypted entries, although they're not useful without key3.db anyway.
I'd guess the problem could be broken logic in the UI, although something in the password manager might not be handling duplicate / near-duplicate entries well.
Comment 8•18 years ago
|
||
I can't reproduce this, will need requested info (in last comment) from reporter to make any headway here. Please reopen when you can supply it.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → INCOMPLETE
Whiteboard: CLOSEME 06/27
I think this is the same bug that i'm guessing. If i remove a few entries from the password manager, then hit "show passwords", the deleted entries show up.
However, this *only* happens when you've put something in the search box, and then hit show passwords. When you take the text out of the text box, the deleted entries do not show up again.
If you're not searching for anything, it all works as intended - the entries delete, even when hitting show passwords. When searching for something after showing passwords, it also works as intended.
Firefox 3.0 beta 2. Hope this helps!
Hobbsee
Comment 10•18 years ago
|
||
erm, getting. not guessing.
Comment 11•18 years ago
|
||
Reopening, as per comment #9.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Comment 12•18 years ago
|
||
Reclosing. :) After talking on IRC it looks like an issue introduced with the Search code added in Firefox 3. So whatever the original bug was filed for, this isn't it.
See bug 405389 for more on this issue.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•17 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•