Yesterday I was doing a regression test for Firefox to determine the changeset which brought in a very annoying behavior into Aurora builds. Therefore I copied my profile to not destroy my original profile data, and was working on that copy. All was working fine and I was able to reduce the whole profile to only the sessionstore.js and prefs.js files.
The evil awakening came today morning when I tried to log into a website via my personal profile. By surprise the user name and password hasn’t been filled in automatically, and a check for the saved passwords have revealed that NONE are stored anymore! All were gone forever.
After some thoughts I figured out that sync was the problem here, because I missed to disconnect it in the copied profile. So after I have deleted the signons.sqlite and other files it also removed all the information from my sync account, which got distributed to all my other machines too. So on each of them the passwords are gone.
And if that isn’t bad enough, the backup tool on my Ubuntu machine had a hick-up lately and deleted all the old backup files on the backup drive. Not sure how that have come, but with that I completely lost all my stored passwords, and other synced data. 🙁
So a warning for everyone who is doing regression tests for Firefox and has Sync enabled: Please do NOT forget to disconnect Sync for the testing profile and double-check that it has been turned off.
Henrik Skupin: Double-check to disable Firefox Sync when doing a regression test to not loose important profile data http://t.co/F73EIglaw2
Isn’t that a bit of a bug in Sync? Surely if your password file is missing or corrupted it should try to restore it rather than pushing the “change” to your account?
Well, I removed the passwords within Firefox because simply removing the signons.sqlite file made the regression disappear. So for a minimized profile I wanted to have at least all my passwords removed. So in that case I don’t call it a bug in Sync.
When testing and developing, I think it would be wise to never use the “production”/main profile. I have shortcuts to run all relevant builds (release, nightly, own builds, UX, etc) with custom profile paths. This also typically avoids any noise/issues the production profile may have due to cruft from extensive usage, and unless you specifically test profile cruft issues, issues are generally more consistent with a clean profile.
E.g. path\to\dev\firefox.exe -no-remote -profile path/to/dev/profile
– The explicit binary path is to make sure it doesn’t use the “global” firefox.exe in case firefox.exe doesn’t exist at the expected folder.
– The -no-remote makes sure it will use the specified binary rather than “piggyback” an already running firefox instance.
– The custom profile makes sure it will not intermix with the production profile.
The problem here is that only my main profile showed the regression. So I had to trim it down. As I have written, I was working on a clone of the main profile, but that doesn’t help if Sync is active.
Maybe you could try one of those file recovery utilities to get back the deleted files?
Oh no!
Note that Sync will only sync deletions if you actually perform a deletion. If you delete the database file that backs the data source (e.g., signons.sqlite) it won’t sync that as a deletion unless you force a reset. But in general, you’re right: don’t do destructive testing on your personal profile!