Closed Bug 78262 Opened 23 years ago Closed 23 years ago

Password manager won't let me delete password: click on OK does nothing

Categories

(SeaMonkey :: Passwords & Permissions, defect)

Product:
SeaMonkey
Component:
Passwords & Permissions
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: rhomolka, Assigned: morse)

References

Details

Attachments

(3 files)

fix bug and two warning messages as well
2.32 KB, patch
Details | Diff | Splinter Review
Patch to allow for deleting an ecrypted password
1.89 KB, patch
Details | Diff | Splinter Review
revised patch to satisfy alecf's comments
3.08 KB, patch
Details | Diff | Splinter Review 
win32 BuildID 2001042704
I screwed up with my hotmail account, and have a blank username/password.  I can
delete the unwanted one from the list in password manager, but it does nothing
when I click OK, just sits there.  Clicking cancel at least closes the window,
but doesn't do what I want.
Experiencing same behavior on build 20010503 Win98.

Procedure: Open the password manager window, assuming that several passwords
such as e-mail and news passwords are already saved there. Open the view stored
passwords window in prefs. If you OK without making any changes it works. Remove
at least one password that is saved here, or remove them all with the remove all
button. Click OK to exit and keep changes.

Expected: Changes are kept and window is closed.

Actual: Window is not closed, and cannot be closed. Cancel can still be used,
though.
Hmm, works for me w98 build 2001050304
Still glitches for me, build 2001050508 Win98. I am saving my e-mail password
and all my NNTP passwords. Try adding news servers that require a
login/password, perhaps.
Works for me too.  Closing this out.

Try this with a brand new profile.  If it still fails, then reopen this bug but 
detail every step that you take (i.e., go to site xxx, fill in form, submit, 
answer yes to save password, open password dialog from task menu, ... )
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
*** Bug 78907 has been marked as a duplicate of this bug. ***
*** Bug 78707 has been marked as a duplicate of this bug. ***
There are too many dups of this bug for me to simply shrug it off as 
works-for-me.  I hope someone can post the detailed set of steps that they took, 
starting from a fresh profile.

Also, can you check the javascript consule to see if you get any error messages 
when you press the OK button.

I'm reopening this because of all the dups.  But unless someone can post more 
details, there'll be nothing that I can do to fix this.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Based on the fact that duplicate bug 78707 was a "new" before it became a "dup", 
I'm upgrading this bug from "unconfirmed" to "new".
Status: UNCONFIRMED → NEW
Ever confirmed: true
This might be the error you're looking for:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIPasswordManager.removeUser]" nsresult:
"0x80004005 (NS_ERROR_FAILURE)" location: "JS frame ::
chrome://communicator/content/wallet/SignonViewer.js :: onOK :: line 383" data: no]
Yes, that error message would certainly explain the behavior being reported.  So 
now to figure out why that error is occuring.

Can you please post detailed steps for reproducing starting with a fresh 
profile.
OK, I just figured out how to reproduce this.  Please stand by.
Status: NEW → ASSIGNED
Here's the story.  Problem occurs when you have saved and then try to delete 
either of the following:

1. Password from a site but you have left the username field (and optionally 
even the password field) blank.  For example, go to 
http://people.netscape.com/morse/password.html, don't fill anything in, and 
press submit.  Then say "yes" to the save-this-password question.

2. Password in a case where there is no explicit username but rather the 
username is determined from the url, as for example a mail url of the form 
mailbox://myname@mail.flashcom.net.  This occurs when saving passwords in the 
mail program.

Now that I understand the cause, the fix is obvious.  Attaching a patch that 
fixes this (as well as fixing to strict javascript errors that I noticed 
during my debugging).
cc'ing matt for review and alecf for superreview.
Target Milestone: --- → mozilla0.9.1
sr=alecf
r=matt
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Verified fixed w2k build 2001050904
Verified fixed mac build 2001050908
Status: RESOLVED → VERIFIED
*** Bug 80584 has been marked as a duplicate of this bug. ***
Re-opening, seeing this behavior on w98 build 2001051404
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Am unable to reproduce this in general.  However I can reproduce it if the 
database is encrypted and I know why that is happening and will have a fix soon.

Terry, was your database encrypted when you observed this problem?
Status: REOPENED → ASSIGNED
Attaching patch.  Problem was as follows.

If the saved data is encrypted, the enumerate routine in the c++ code was 
appending the string "(encrypted)" to the username so that the password-manager 
dialog could display that information.  In other words, if username is "jack", 
the dialog would display "jack(encrypted)".

Problem is that when we delete a username/password, we were passing that 
username string (with the encrypted notation) back to the c++ code and the c++ 
code was looking for an exact match and not finding it.

Fix is for the c++ code to not append anything.  That way the javascript in the 
dialog could save away the raw username that it was passed, and return that raw 
name to the c++ code if the entry needs to be deleted.  Furthermore, the 
javascript could do its own appending of "(encrypted)" before displaying the 
username, so we can still tell the user if the database is currently encrypted.
I do not use encryption and still have this bug. The bug is not that something
is not deleted - it's that 'OK' button doesn't really take effect on this
dialog, so nothing ever happens with it.
requesting review from matt fisher, superreview from alecf.
Terry, I understand that the problem is that the OK key doesn't seem to be doing 
anything.  What's happening is that a javascript error is occuring and that is 
what is preventing the code that handles the OK from completing.

There definitely is a problem with encrypted values and the patch that I just 
posted will fix that.  But if you are not using encryption, then there might be 
yet another problem.  Can you attach a screenshot of the hostnames and usernames 
appearing in the dialog.  Thanks.
Terry, also give me the text of any error message that appear on the javascript 
console when you click OK.
Will do now
yes, i am using encryption and the error in the javascript console is uncaught 
exception: null
OK, if you are using encryption, the problem is what I thought it was.  And the 
patch I just posted in this report will fix it.
we shd be nominating the bugs as nsbeta1 if we're working on them in this 
milestone. nav triage: we're moving this to mozilla0.9.2 as it doesnt sound like 
a beta stopper at this point. 
But we already have a patch for it.  So why move it out?
I have the following JS error after pressing OK:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIPasswordManager.removeUser]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://communicator/content/wallet/SignonViewer.js :: onOK :: line 383"  data: no]
Yes, that's the error that the patch posted here will fix.  Thanks for listing 
the error.
1) please use NS_FAILED, not !NS_SUCCEEDED
2) "(encrypted)" is not localizable, please use a localized string (preferably
using FormatStringFromName, since you're composing strings) to display that the
user is encrypted...
ya, what he said,  r=matt
I'm attempting to move the non-beta stopping bugs to m0.9.2 as per the PDT 
guidelines for Netscape contributors. Please check the patch in only for m0.9.2. 
thanks, Vishy
Target Milestone: mozilla0.9.1 → mozilla0.9.2
sr=alecf
I have this same problem, using Win2K Professional with SP1 and "Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:0.9) Gecko/20010505". IMHO, the Severity
should probably be higher then minor, primarily because not being able to delete
a password could be a security issue.

Regards,
Jim Wilson
Oops, I checked in this fix on May 17 but forgot to close out this report.  So 
marking as fixed now.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Verified fix checked into lxr.mozilla.org
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: