203207 - unable to open password manager

Status: RESOLVED EXPIRED

(SeaMonkey :: Passwords & Permissions, defect, P1)

Description

[Ralf Hauser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030423
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030423

Contrary to http://bugzilla.mozilla.org/show_bug.cgi?id=127344, I don't think
this is the problem of a corrupt password file because for example the password
for this bugzilla was provided without any problem.

I noticed it already on my 20030415 build and downloaded the newest one and it
is still there?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Tim Richardson]

I can not open the password manager all of a sudden. Attempts to do so are
silently ignored. I first noticed this problem because logins in to read mail
were giving password errors, in two different profiles. This implies some
corruption, weird that it happens in two different profiles at almost the same
time. 

My build is 1.4 release, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
Gecko/20030624 (Windows XP SP1)

I don't know what to do, I don't even know which file stores the password database.

Comment 2

[Kai Engert (:KaiE:)]

I think the two comments refer to different problems.

In comment 1, the password retrieval mechanism works, but in comment 2 it does not.

Please check whether Tools/JavaScript shows any messages that appear to be relevant.


If password manager is still supplying passwords, but the password manager does
not open up, I do not have an idea what to do. Try to change your "master password".


If your password manager is no longer supplying passwords, and the manager does
not open, this sounds like the required crypto key is gone. It is stored in the
*.db files in your profile directory. Unfortunately, there is no way to check
whether the key is still there.

I guess you will have to clean up the problem manually. If you still know your
master password, try to change it. Back up all your certs, if you have something
important. Try to edit prefs.js and find out the filename that stores the wallet
data. Remove those files and the pref, resetting it to the original state. You
will loose all your passwords, but it's probably better than to delete the whole
profile.

I only saw this kind of error when I manually tweaked with the *.db files in my
profile directory (for testing purposes).

Since I never saw the problem myself otherwise, I'm resolving this bug as
WORKSFORME.

Comment 3

[Tim Richardson]

This is a follow-up to the second comment.
The master password still works, and the website passwords that I checked still
work. I only had problems with the mail accounts. When attempting to log on to
the mail servers, it seems to loop, telling me time after time that the attempt
to logon failed. I can only stop it by forcing the browser offline. I then
deleted likely looking records from the .s file. 


However, I still can not bring up the dialog to 'manage stored passwords'. I get
a n hourglass icon for a second, and then nothing.

There are no relevant messages in Web Development -> Javascript Console.

Comment 4

[Kai Engert (:KaiE:)]

Tim, thanks for the follow up comment.

I have to confess I'm now able to reproduce the problem myself. I see it in two
different profiles, with both 1.3.1 and 1.4, and both combinations of "use
encryption" or not.

Something is really wrong.

Now that I am able to reproduce, I should try to understand what is going on.

However, since the problem appears, too, when encryption is not used, this can
not be a PSM problem, but should be a Wallet problem.

Comment 5

[Kai Engert (:KaiE:)]

Reassigning and confirming.

Comment 6

[Kai Engert (:KaiE:)]

Over to me, because I can reproduce and probably should debug it. But feel free
to jump in and help.

Comment 7

[Kai Engert (:KaiE:)]

I looked around and the reason for the password manager window not showing up
is, the password data file has unexpected contents.

However, in two of my profiles I have different content that causes it to fail.
I wonder if invalid data in the data file only occurs after having used buggy
nightly builds of Mozilla, or whether wallet produces damaged data occasionally
even with release builds.

In one of my profiles, some of the stored passwords where encrypted, others
where not. The loading code of the dialog detects the incosistency and simply
stops the dialog (by closing it) without giving feedback to the user :-(
After removing all sections from one type of passwords from the file I could
open the dialog again.

In the other broken profile, I had two additional separator lines, i.e. I had a
sequences of two lines containing a dot (.) each. After removing the additional
lines, opening the dialog worked with this profile again, too.

So, I don't have an idea what to do about this bug.

Are we aware of many users with this problem?
Or does it only happen rarely, and only for users who use alpha/beta/nightly builds?


-> back to default module owner

Comment 8

[Tim Richardson]

Regarding use of beta/nightly builds: on this computer, nothing more recent than
the 1.4 release has been used, not even Mozilla Firebird. I use encryption.

I will email my .s file to someone if it would help. Despite the encryption, I
am reluctant to post it to bugzilla. 

There are two profiles in common use on this computer. Both of them had POP
server password problems, on one of them I was able to use the password manager
to delete the somehow-bad passwords, on the second profile this is when I
realised I could not use the password manager to edit the password entries. One
thing maybe a little odd is that both profiles have a pop account in common
(with setting 'no delete on server after download'), but the mail directories
are different. 
After manually editing the file to delete the bad POP entries, that problem is
solved. The "new" passwords were saved by Mozilla (actually, there was no
change) and email is working again (but not the Password Manager). 

Comment 9

[Greg Mohr]

I had a similar problem when upgrading from Mozilla 1.3 to 1.4.  I created a new
profile and copied my old .s file to my new profile and updated prefs.js as
directed in many FAQs, but the Password Manager dialog would not display unless
I erased all my saved passwords from the .s file.  I went to a site for which I
had previously saved a password, logged in, then told Mozilla to save my
password. I compared the contents of the .s file in my new profile with the .s
file in my old profile, and I noticed that no entry matched between the two files.

I had enabled the "Use encryption when storing sensitive data" option in 1.3,
and after reading comment 2 I thought maybe I should copy my *.db files from my
old profile to my new profile.  I did that, recopied my old .s file to my new
profile, and Password Manager began working as it had under 1.3.

If encryption is enabled for saved passwords, at least one of those .db files is
critical for decrypting the contents of the .s file, so at a minimum the Mozilla
1.0 FAQ section 7.6 (http://www.mozilla.org/start/1.0/faq/profile.html) should
be updated to include that information.  Also, it would be nice if Password
Manager would display an alert (like "Corrupted password data") instead of
silently failing.

Comment 10

[Kent S.]

I have just experienced perhaps the same problem in 1.4 (XP Pro SP1).  I tried
to open Password Manager (Tools|Password Manager|Manage Stored Passwords). 
Nothing happened.  I tried again ... I started to hear hard drive thrashing, my
memory spiraled to 0 and Mozilla crashed.  I restarted Mozilla; repeated the
steps and same result.  I rebooted and restarted Mozilla; same.

So then, without opening Password Manager, I added a new password (ironically, I
was trying to change my e-mail address for Bugzilla) ... and now it works fine
again.  Corrupt and now fixed ".s" file?  I don't know.

Comment 11

[Ralf Hagen]

I get similar results when using Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT;
rv:1.4) Gecko/20030624. The problem lingers for about a year now with differend
versions; I had 1.2.1, 1.3b, 1.3, 1.4 until now.
Could perhaps someone give some clue as how to look for in order to repair the
abc.s file?

Bug #127344 seems to be a duplicate of this bug.

Comment 12

[Christoph Pohl]

same as comment 11 for me with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040122 Debian/1.6-1 and also dating back to 1.2.1 and before!

Comment 13

[manfred meiser]

i am using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
Gecko/20040113 on XP Pro and had the same with the older version as well
problem! the password manager would just not open!
but contrary to other users the actual feature was working well. no matter if
pop or other saved passwords.
i now just deleted the all of my *.s files, logged off and on, launched mozilla
and let mozilla create a new one and refill it by going to different pages - it
worked and i can open my manager now!

my troubles started when i encrypted my passwordfile by using the optional
funktion of this browser. i also had 2 *.s files in my profile and i was not
able to figure out which one is in use!

i think that the encryption is messing the whole thing up.
i turned it off now btw.

Comment 14

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420