There have been a number of bugs in Firefox Health Report that can be attributed to preference writes never being flushed to disk. Presumably other features are also affected if preference writes never flush. The assumption of many users of preferences is that changes to preferences will eventually be persisted - except if there is a process crash or some other extreme event. AFAIK, we don't currently know what percentage of our users experience lack of preference persistence. I propose we add Telemetry to measure it. Here is my proposal. Every time the app starts, we generate two UUIDs. Let's call them A and B. We write both UUIDs to a file or some other known persistent store. Also at application start we write A to a preference, say preferences.persisted.startupID. At shutdown time, we write B to a preference, say preferences.persisted.shutdownID. Cool. When the application starts, we read the known good UUIDs from the filesystem or wherever. We also read the UUIDs from preferences. We compare and record in Telemetry figures for {startup pref persisted, startup pref lost, shutdown pref persisted, shutdown pref lost}. This could all be in 1 histogram with enumerated buckets so we have a single graph showing us the state of the world. After we record that Telemetry result, we proceed to the previous paragraph and generate new IDs and do it all over again. Unfortunately, the additional I/O to a robust store could adversely affect startup performance. In addition, there is a chance that the writes to preferences could trigger an otherwise not required flush of preferences to disk on shutdown. I'll let someone else weigh the perf concerns against the benefit of obtaining this data. But, some workarounds are a) delay comparison so startup isn't adversely affected b) only enable this on select branches c) only enable for a limited period of time d) only check preference persistence every N app restarts. Finally, this bug probably doesn't require changes to the prefs backend. I just figured this would be the best component for it. Module members may also be aware of known issues around lost preference persistence.

We already sync the prefs file on startup as part of the startup crash detection. The prefs file gets flushed early during startup and also ~30 seconds after startup. http://mxr.mozilla.org/mozilla-central/source/toolkit/components/startup/nsAppStartup.cpp#931 http://mxr.mozilla.org/mozilla-central/source/toolkit/components/startup/nsAppStartup.cpp#984 I think you might be able to use these startup crash prefs instead of adding a startup UUID. We might want to add Telemetry on how long it takes to do a prefs flush. For checking if prefs were written out at shutdown, you could just set a "correctShutdown" flag in the prefs right before prefs get flushed on shutdown (and reset it on startup). I would be very interested in seeing this number. I know it used to be the case that 10% of Firefox shutdowns lead to a corrupt network cache because Windows would terminate Firefox if it took longer than 10 seconds to exit during an OS shutdown. This might be one possible source of the prefs data loss.

Actually, do we even need the startup UUID? We know flushes are going to happen 30 seconds into startup, so is there any value to having it?

I think the purpose of the startup ID is to invalidate the shutdown ID. If you rapidly launch and quit, you lose the pairing, and you are closer to knowing which startup did not flush prefs. I don't know if that's valuable enough to be worthwhile.

I think the correctShutdown approach would work, so long as we have the chance to record failure before the user quits the browser!

My proposal was based off information I didn't know until Vladan enlightened me in comment #1. By all means change the proposal to do what makes sense! We should also consider the desire to implement session tracking in Gecko for bug 841561. I predict all this culminating with an append-only log of session events with useful information gleaned by replaying the log. But, that is beyond this bug. Just something to think about...

We now automatically write prefs.js within 500ms of any pref change. This isn't perfect durability, but it's pretty close, so I think this bug can be closed.