Prefs should be automatically saved when dirty

RESOLVED DUPLICATE of bug 981818

Status

()

P3
enhancement
RESOLVED DUPLICATE of bug 981818
17 years ago
a year ago

People

(Reporter: bnesse, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
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.
Depends on: 160377, 161701

Comment 2

17 years ago
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

Comment 3

17 years ago
--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

17 years ago
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!

Updated

15 years ago
Blocks: 123929
Assignee: bnesse → nobody
Status: ASSIGNED → NEW
QA Contact: rvelasco → preferences-backend

Updated

6 years ago
Priority: -- → P3

Updated

5 years ago
Duplicate of this bug: 910298
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.