User Agent: Mozilla/5.0 (Windows NT 6.1; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 Build ID: 20140612174402 Steps to reproduce: Update from Seamonkey 2.26.1 to 2.29b1 or 2.29b2. Actual results: Saved passwords would not populate the password field as usual on a web site with a previously save password. Look in Password Manager - click manage stored passwords and then select "passwords only" from the upper LH pull down menu. Domain list is blank. Uninstalled 2.29b2 and reinstalled 2.26.1 - all passwords returned and function normally. Same issue occurred with 2.29b1. Same thing happened on two different windows machines that I use. Expected results: Passwords should appear in the appropriate field on a web site that I have previously saved a password for.

Expected behavior, you might say. See, "Firefox 32.0 - Saved Passwords Aren't Showing" http://forums.mozillazine.org/viewtopic.php?f=38&t=2864933 The same applies to SeaMonkey. (I made a suggestion yesterday that this situation should be relnoted for the 2.29 release.)

Workaround 1: If you want Firefox 32.0 to take another crack at importing your passwords, 1. In about:config, right-click signon.importedFromSqlite and choose Reset. 2. Type about:support into the address bar and press Enter. 3. Click the Show Folder button. 4. Exit Firefox. 5. Delete the logins.json file from the profile folder. This assumes you didn't save or modify any passwords in Firefox 32.0. If you did, not only will they all be lost, but the key3.db decryption Workaround 2: There's a neat Password Exporter add-on: https://addons.mozilla.org/addon/password-exporter/ Install it, then you get an option to import/export your passwords on the Tools>Options>Security tab. Export Passwords file which is automatically dated to .xml or .csv. Then install 32.0 or greater. You can then simply import all your passwords effortlessly.

Oh, moving to Toolkit | Password Manager, letting Mozilla decide if anything needs or should be done with this, or to just say "it's expected" & mark as Invalid.

You might want to take a look at bug 1030059, it could be the same issue.