Recently Bill Law and I determined that a number of consumers of preferences are saving the prefs file to disk. This ended up being the (a?) cause of bug 155080. I discussed this with alecf, and he suggested that this is being done because consumers want to insure that "their" preference gets written out to disk so that it isn't lost in the event of a crash. He suggests implementing a model similar to the one used in history which uses a timer to check for a dirty state and subsequently flushes the file out to disk. This will allow us to remove all of the extraneous calls to SavePrefFile() and probably reduce disk hits caused by unnecessary preferences saving.
There are (at least) 2 things that stand in the way of this being a beneficial enhancement. One is the ability to know when prefs are saved. The second is to eliminate any "constantly dirty" preferences... one such preference is the "browser.history.last_page_visited" preference. There may be others, this just happens to be one that I am aware of. Adding these bugs as blockers.
see also global history, which uses a timer-based mechanism to flush history to disk. the way it works: 1) a dirty flag and a timer are stored 2) when history changes, the dirty flag is set and the timer is set to some time in the near future (1 minute maybe?) 3) when the timer fires, changes are flushed to disk 4) when history changes while the dirty bit is still set, the timer is pushed slightly further into the future. This allows us to avoid saves where a number of changes occur in a short time period, but to save when things are "idle" at least from history's perspective. I think a similar approach should be used for preferences...the other bonus of using this approach for prefs is that you aren't constantly saving minor prefs changes and losing an older prefs.bak (save-save) file.. with the above mechanism, changes are batched before writing the file.
Status: NEW → ASSIGNED
--clip-- <tr> <td class="Data Center"> <input class="ButtonRed" type="submit" value="Valider"> <input class="ButtonRed" type="reset" value="Réinitialiser"> </td> </tr> --clip-- The web programmer didn't use the "valign='center'" within the <td> script so that would explain why the text and the button looked funny. It should be like this. Not sure about the images though. --clip-- <tr> <td class="Data Center" valign='center'> <input class="ButtonRed" type="submit" value="Valider"> <input class="ButtonRed" type="reset" value="Réinitialiser"> </td> </tr> --clip--
Oops! Wrong bug number! So, sorry for the mess-up! It is the human-factor and interface-design problem on the bugzilla software itself. I finished posting a comment to the bug #161708 and press commit. Later on, I came back to post it again not realizing the bugzilla had moved to the next bug in the list. Gee! What a waste!
Assignee: bnesse → nobody
Status: ASSIGNED → NEW
QA Contact: rvelasco → preferences-backend
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 981818
You need to log in before you can comment on or make changes to this bug.