Closed
Bug 479799
Opened 16 years ago
Closed 16 years ago
passwords imported from SM 1.x not being saved after SM 2.0 installation
Categories
(Toolkit :: Password Manager, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: epp, Unassigned)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090218 SeaMonkey/2.0a3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090218 SeaMonkey/2.0a3
Once installing SM 2.0a3 for Linux and selecting to import everything from a previous SM 1.0 installation, the imported passwords are only saved for that first session, the Password Manager displays the information. Once launching SM a second time, the mail/news passwords are gone and the Password Manager is empty.
On the Clear Private Data selection, "Saved Passwords" is NOT checked.
Reproducible: Always
Steps to Reproduce:
1. Install SM 2.0a3 and select to import everything from SM 1.0
2. E-Mail works on first session.
3. E-Mail does not work on second session as the passwords did not save.
Actual Results:
Passwords were not saved after installation of SM 2.0a3. Password Manager was empty.
Expected Results:
Passwords should have been saved.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 SeaMonkey/2.0a3 - build 2
It works fine in Windows XP SP2.
Version: unspecified → Trunk
2.0a3 was installed on three machines, this only occurs on one (laptop with 1.8 GHz Intel Pentium M CPU, 1.5 Gb memory).
Problem appears to be similar to bug 458511 filed against Firefox.
On the one system where this occurs, I am constantly prompted to re-input the mail server password, the box to have Password Manager remember it, IS checked. When I then click OK, an "Alert" box appears with "Error getting mail password".
The only way it will work, is per-session, while NOT checking the box to have Password Manager remember it.
If I delete the ~/.mozilla/seamonkey directory and start over, allowing it to re-import the passwords from the SM 1.x installation all over again, the resulting behavior is as described in the Description.
Component: MailNews: Account Configuration → Passwords & Permissions
Build ID: 20090301000442
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090301 SeaMonkey/2.0b1pre
Problem still present in this nightly.
Reporter, Duplicate to Bug 474846 ?
I cannot say that this is a duplicate because the Password Manager is empty upon the second launch of SM 2.0.
Bug 474846 also mentions data loss but the referenced information indicates items are present in the Password Manager.
Updated•16 years ago
|
Component: Passwords & Permissions → Password Manager
Product: SeaMonkey → Toolkit
QA Contact: mailnews-account → password.manager
Comment 7•16 years ago
|
||
This would be 474846 if the initial import failed. It sounds like you do see them imported, but then they disappear next time the SeaMonkey is started?
Can you check to see if there's a signons.sqlite in your profile after the initial import (but before quitting) and after restarting?
Also try enabling debugging ala https://wiki.mozilla.org/Firefox:Password_Manager_Debugging, and see if anything is reported?
The passwords are imported first, but then they disappear the next time SM is launched.
After initial import (and before quitting), there was no signons.sqlite file in the profile directory.
After quiting and restarting, signons.sqlite was then present.
After turning on the debug logging, the Error Console displayed a list of these:
PwMgr Storage: Failed to encrypt string. (NS_ERROR_FAILURE)
PwMgr Storage: 2E upgrade: set empty realm to <name of mail server here>
Comment 9•16 years ago
|
||
It's not clear what's happening here. I really need to see a full debug log, with the debug pref enabled before importing.
Bug 433070 recently found that importing from SeaMonkey is completely busted, so I'm not really sure exactly what this bug was doing in the first place.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
Comment 10•16 years ago
|
||
This bug here was about importing passwords from SM 1.0 to SM 2.0 btw, so it was not affected by the bug in the Firefox import code.
You need to log in
before you can comment on or make changes to this bug.
Description
•