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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Reassigning and confirming.
Assignee: ssaux → dveditz+bmo
Status: UNCONFIRMED → NEW
Component: Client Library → Password Manager
Ever confirmed: true
Product: PSM → Browser
QA Contact: bmartin → tpreston
Version: 2.4 → 1.4 Branch
Over to me, because I can reproduce and probably should debug it. But feel free to jump in and help.
Assignee: dveditz+bmo → kaie
Priority: -- → P1
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
Assignee: kaie → dveditz+bmo
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).
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.
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.
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.
No longer blocks: 127344
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!
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.
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
Status: NEW → UNCONFIRMED
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago → 9 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.