Sometime in the last 1-2 weeks all my saved passwords went away. I've had this profile for years, but I noticed I was having to re-enter everything. So I went to password manager and there were only ~20-30 entries. There used to be thousands.

@mattn said it might be fallout from bug 853549.

and/or the interaction with Sync (e.g. bug 1017305)

We haven't deleted signons.sqlite from profiles yet, are they still in there? Probably interesting to compare both what sqlite3 says from the command line, as well as what and older Firefox sees -- copy signons.sqlite and key3.db to a temporary profile to check. [These can differ, as if the stored entries can't be decrypted they won't show up in the password manager UI (prefs->security->show passwords).] If they're not there, something happened prior to bug 853549. If they are, can you then run a current Firefox against that temporary profile, and see if they're successfully migrated to the new logins.json (just check in the pwmgr UI again). I hope the migration breaks, because otherwise this will be mysterious to track down. :(

Passwords show up fine a temp profile in release Firefox, and migration to Nightly worked a-ok :( How can I test re-migrating in my real profile? Eg, can I delete the new json file and start? Or is there a pref as well?

You need to flip signon.importedFromSqlite

Does this profile use Sync? It would be great to know if we need to consider that as a factor (as mentioned in comment 2)

Sorry, mentioned to Matt on IRC and forgot to note it here: Was using old sync, and upgraded to new sync a few weeks ago.

rnewman, FYI, sync is somewhat implicated here - it's unlikely Sync is actually at fault, but things aren't clear.

You can check whether your profile contains non-decryptable logins by running these two commands in the Browser Console: Services.logins.getAllLogins().length => Prints the number of decryptable logins only Services.logins.countLogins("", "", "") => Prints the number of all logins including non-decryptable logins Non-decryptable logins may be present when a profile is used on a different computer, or when the key3.db file is deleted or replaced.

Thanks Paolo. 23 & 23. My signons.sqlite has many hundreds more. I'll try flipping the pref and re-importing today.

(In reply to Dietrich Ayala (:dietrich) from comment #10) > Thanks Paolo. 23 & 23. My signons.sqlite has many hundreds more. I'll try > flipping the pref and re-importing today. Thank you Dietrich! If that doesn't work as expected in your profile, you may find reports in the Error Console about the rows for which the import failed.

Any success in re-importing the passwords?

The re-import failed! I forgot to check the logs though. Will re-import again.

I believe this issue might be something specific to your configuration, since the feature has been on Aurora for some time now and I've not seen similar reports. However, in case the error log says something interesting, I'd be curious to know what is going wrong with the database, and understand if this is an edge case we should handle in some way.

There are many bugs that get shipped with no reports, and some that never get reported. Non-technical users often just throw their hands up and move on. I can email you my passwords files if you want to try and debug.

(In reply to Dietrich Ayala (:dietrich) from comment #15) > There are many bugs that get shipped with no reports, and some that never > get reported. Non-technical users often just throw their hands up and move > on. > > I can email you my passwords files if you want to try and debug. That's fine with me!

Emailed signons.sqlite & key3.db in encrypted zip, sent password via different communication channel. Please don't read my diary or empty my offshore accounts.

(In reply to Dietrich Ayala (:dietrich) from comment #17) > Emailed signons.sqlite & key3.db in encrypted zip, sent password via > different communication channel. > > Please don't read my diary or empty my offshore accounts. I can promise I won't do one of those two things - I'll be glad to leave the choice to you :-P Sent you an e-mail with further instructions :-)

I just ran in to this. I had been using Firefox release (30, then 31) due to an issue with OMTC on Nightly. Today I switched over to using Nightly and I only have 3 passwords remaining. I have been using new Sync, and my phone still has my passwords present and working. Running the commands referenced in comment #9 returns 3 & 3.

(In reply to [Away for most of July] (please needinfo? me) Jared Wein [:jaws] from comment #19) > Running the commands referenced in comment #9 returns 3 & 3. If you retry the import after deleting the JSON file and resetting the "signon.importedFromSqlite" preference, do you see any messages in the Error Console?

Marc, do you know if anyone from QA can help in reproducing the issue? It seems to happen on profile migration with new Sync enabled.

[Tracking Requested - why for this release]: Possible regression from bug 853549 and new Sync.

Richard, is there anything obvious to you that may cause this behavior from the interaction of the Password Manager and new Sync?

Maybe related to bug 1017305? There doesn't seem to be much progress there, I wonder if the issues with the Sync tests went away.

(In reply to :Paolo Amadini from comment #23) > Richard, is there anything obvious to you that may cause this behavior from > the interaction of the Password Manager and new Sync? Nothing I know of. FxA Sync uses the exact same password sync code as Sync 1.1, just as it does for all engines, so any failure should hit both sets of users. The only changes to the password sync engine in the last few months were work that you know better than me: changeset: 185321:a3f383647966 user: Paolo Amadini <paolo.mozmail@amadzone.org> date: Tue Jan 07 17:29:41 2014 +0100 summary: Bug 853549 - Use a JSON storage back-end in the Login Manager, except on Android. r=dolske changeset: 194224:d0050ba0b875 user: Mark Hammond <mhammond@skippinet.com.au> date: Thu Jun 12 18:19:49 2014 +1000 summary: Bug 1013064 (part 5) - stop disabling the password engine when MP enabled. r=ttaubert changeset: 195294:f09caa4ea7c5 user: Neil Deakin <neil@mozilla.com> date: Mon Jul 21 09:09:41 2014 -0400 summary: Bug 1013064, backout e5dfe9801f76, 11f3a97d1d2c, e2374762f521, 91db8acb8d7e, d0050ba0b875 due to sync issues I suppose it's possible that if you used a version between June 12 and July 21, and it was buggy, then something might have gone wrong.

Paolo, Tracy Walker is the QA tester for Desktop Sync. Edwin's team owns the back end testing. I'll needinfo Tracy for follow up.

(In reply to :Paolo Amadini from comment #21) > Marc, do you know if anyone from QA can help in reproducing the issue? It > seems to happen on profile migration with new Sync enabled. Paolo, what do you mean by profile migration? Are you referring to comment #3?

(In reply to Dietrich Ayala (:dietrich) from comment #17) > Emailed signons.sqlite & key3.db in encrypted zip, sent password via > different communication channel. Paolo, did you have a chance to look into recreating with Dietrich's data?

(In reply to [:tracy] Tracy Walker - QA Mentor from comment #27) > Paolo, what do you mean by profile migration? Are you referring to comment #3? I meant updating from 31 to 32, when the contents of the "signons.sqlite" file in the profile folder are migrated to "logins.json". This seems to have issues in cases that are still unclear, though we suspect it may be related to profiles with Sync enabled. The feature was tested extensively with the cases listed in <http://goo.gl/t07m0K>, including Sync migration, so there should be something we overlooked. Let me know if you have any question about the steps to reproduce. (In reply to Justin Dolske [:Dolske] from comment #28) > Paolo, did you have a chance to look into recreating with Dietrich's data? The problem does not occur on a different profile with the same data, and Dietrich was on PTO for the last three weeks so he couldn't execute a few more tests I asked nor send me the broken "logins.json" for comparison. And apparently Jared is currently on PTO too. Here is an expression that can help in understanding which range of passwords were migrated in a new profile: new Date(Math.max.apply(Math, Services.logins.getAllLogins() .map(i => i.QueryInterface(Components.interfaces.nsILoginMetaInfo) .timeLastUsed))).toString(); This can be used to get .max. and .min. values for .timeLastUsed and .timeCreated. Strangely Dietrich told me there was no output in Scratchpad when he executed this command, which is mysterious, but this is where we stopped. I believe Dietrich is back so we may be able to do some more debugging depending on his availability, including retrying with add-ons disabled.

Flipping the signon.importedFromSqlite and restarting Firefox didn't fix the issue, however switching back to Release (v31) did fix the issue for me.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #30) > Flipping the signon.importedFromSqlite and restarting Firefox didn't fix the > issue, however switching back to Release (v31) did fix the issue for me. To follow up on this, I had to also delete/rename the logins.json file, reset that pref, and then restart and they reimported correctly.

We figured out what happened in Jared's case thanks to an ad-hoc debugging session. Without describing all the details, this is more or less the sequence of relevant events: * The code for the conversion to JSON landed in Nightly on May 28 (Firefox 32). * Jared was using Nightly at the time, and the JSON conversion worked for him without issues. * On June 17, when Nightly was 33 and Release was 30, Jared started using a new laptop. * The new laptop had a blank profile. He used it for a short time, typing a few passwords manually. * Because of issues with Nightly 33, he reverted the blank profile back to Release 30. * He set up sync on the blank profile, so that all his passwords were imported. * On July 23, Jared swithed back to Nightly 34 from Release 31. * At that point, Nightly used logins.json, that contained only the passwords he typed in June. * The recovery procedure he tried yesterday migrated all the passwords again. So, clearly Sync was not directly involved here. What was non-obvious at first is that we were dealing with two different profiles at different times. I believe this case falls into those for which we explicitly don't provide automated merging, and recommend the recovery procedure.

Dietrich case is different. I queried the creation dates for the passwords in the partial logins.json, and it turns out that those were all created after the conversion to JSON landed in Nightly on May 28. The passwords in the SQLite database were all last used a few hours before the first one in the JSON file was created, as expected. This means that something didn't work once, and the migration didn't happen at all, thus it lets us exclude that a partial migration happened because of some mysterious race condition. There may be various reasons for the failure, including locks or glitches while reading the SQLite database. Since the problem does not happen anymore, we can't be sure of what happened exactly, but it can be specific to Dietrich's system or the various add-ons that were active at the time. When retrying the recovery procedure with the same configuration later, everything worked fine. Also, I've noticed that at some point Sync was able to restore many of the passwords that weren't imported originally to logins.json.

Based on the successful investigation and reconstruction of both cases, and the fact that both were satisfactorily resolved by the recovery procedure, I think there is no action needed and we can close this bug. We should still be on the lookout for regressions and new bugs that may be reported, of course.

my ff just updated to 32 today, and in the process lost all my passwords, and the sync page sticks on 'determining account status' the remove signons.json and reseting the about:config option didn't fix the issue. reinstall 31 and everything is fine, passwords are there, sync page is fine, try backing up passwords using password export and febe just in case. reinstall 32, same issue, no PW and sync page stuck, try to import passwords using febe or import password button, does not import passwords, so at this point v32 is completely broke and useless on my laptop fyi sync only connected to this computer, phone and tablet, with the computer being the 'master' firefox

av8or: please file a new bug for tracking your issue. It would also be helpful if you could create a new profile, enable debug logging per http://wiki.mozilla.org/Firefox:Password_Manager_Debugging, and then reimport your logins. (I can give you more detailed info in the new bug you file, if needed.)