161711 - Prefs should be automatically saved when dirty

Status: RESOLVED DUPLICATE of bug 981818

(Core :: Preferences: Backend, enhancement, P3)

Description

[Brian Nesse (gone)]

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.

Comment 1

[Brian Nesse (gone)]

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.

Comment 2

[Alec Flett]

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.

Comment 3

[Sam J. Fleet]

--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--

Comment 4

[Sam J. Fleet]

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!