User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/20091023 SeaMonkey/2.0.1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168pre) Gecko/20091023 SeaMonkey/2.0.1pre While Migration Wizard does migrate passwords, it does not correctly migrate Composer Publish Settings site login information correctly. The passwords are not formatted correctly & so are not usable with Composer Publish Settings. Further if you attempt to create & save a new Publishing Site (& Save Password), data loss occurs, where you loose all but the first (previously) saved Publish Site (prefs.js) records, & the "saved" password data does not get updated into Password Manager. Reproducible: Always Steps to Reproduce: SeaMonkey1: 1. create new Profile 2. open Composer, Edit | Publish Site Settings... 3. create (3) test Server Sites, including saving the username/password 4. close SM1 SeaMonkey2: 1. run seamonkey -P 20.dumy2 -migration 2. open Password Manager. verify that the FTP (Composer) sites have migrated. 3. open Composer, Edit | Publish Site Settings... 4. verify that the "Sites" appear, including the "User name:", but no password data appears Actual Results: Password: field data is blank Expected Results: Password: field data should be filled in with the migrated password, obtained from Password Manager Appears that SM1 is storing in PWM the "site" such as ftp://user_name@publishing_address, but the migration of the password data into SM2 PWM is truncating that, storing only ftp://publishing_address. It is dropping the user_name part. Because of that, there is no longer a correlation between PWM & Site Manager, hence no password displays or is used if you attempt to publish. SM1 will not save a password unless both the User Name: and Password: fields are filled out. Further it appears that if you were to add a New Publish Site from within SM2, Composer, that all but the first (previously saved <you did make 3 sites in the outset>) sites then disappear from Site Manager (& prefs.js). At that point, it looks like both prefs.js & signons.sqlite are corrupted. prefs.js has lost all but one Publishing Site Settings data set, & signons.sqlite will no longer save Publishing Site passwords (though the existing ones do remain & new "regular" passwords are being saved). Just to note: On a -migrate, *.s is being copied over from SM1 into the SM2 Profile, along with the Preference signon.SignonFileName pointing to *.s is being set in prefs.js. Publish Settings (editor.publish.site*) prefs.js data entries between SM1 & SM2 look to be equivalent. /Natively/ created Publish Settings Site password as stored in Password Manager, are stored differently between SM1 & SM2. SM1, the "Site" field in Password Manager shows as: ftp://user_name@publishing_address <this is truncated on migration> SM2, the "Site" field in Password Manager shows as: ftp://user_name@publishing_address (ftp://user_name@publishing_address) <the "Site" is displays as shown including the duplication in the parentheses, for whatever reason> There is good potential for data loss, both in prefs.js & signons.sqlite.
Created attachment 409525 [details] SM1 Publisher/PWM SM1 Publisher & Password Manager shots. Publisher password is there (though obscured). PWM "Site" is of form ftp://user_name@publishing_addr.
Created attachment 409527 [details] SM2 Publisher/PWM Migrated SM2 Publisher & Password Manager shots. Publisher password is missing. PWM "Site" is of form ftp://publishing_addr. The user_name@ has been truncated.
Created attachment 409528 [details] SM2 natively created Publisher/PWM SM2 natively created Publisher & Password Manager shots. Publisher password is there (though obscured). PWM "Site" is of form ftp://user_name@publishing_addr (ftp://user_name@publishing_addr).
Component: General → Passwords & Permissions
QA Contact: general → privacy
therubes reports are usually pretty reliable. And there are known problems with our migration code wrt Composer passwords.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [CLOSEME INVA/WONT?] → [DUPEME]
You need to log in before you can comment on or make changes to this bug.