bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

preference binding doesn't flush prefs after a clearUserPref




5 years ago
5 years ago


(Reporter: Ian Nartowicz, Unassigned)


23 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [bugday-20131028][DUPEME?])



5 years ago
User Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0 (Beta/Release)
Build ID: 20130509111054

Steps to reproduce:

Set the valueFromPreferences property (or the value property in instant apply mode) of a preference element to undefined

Actual results:

The preference is cleared to its default value but the preference file is not flushed to disk.  In the event of a crash, the preference would retain the value from before it was cleared.

Expected results:

When preferences are set to a value other than undefined using a preference element, the preference is changed and then the file flushed to disk.  Seems like this should be done for both setting and clearing.

Comment 1

5 years ago
I noticed this when setting and clearing multiple preferences.  Creating them was extremely slow due to the repeated synchronous flushes of the prefs file, but clearing them was fast.


5 years ago
Whiteboard: [bugday-20131021]

Comment 2

5 years ago
bug 161711?
Component: Untriaged → Preferences: Backend
Product: Firefox → Core
Whiteboard: [bugday-20131021] → [bugday-20131028][DUPEME?]

Comment 3

5 years ago
(In reply to Aleksej [:Aleksej] from comment #2)
> bug 161711?

Fixing bug 161711 would presumably fix this bug because then nobody would have to explicitly flush preferences, not even prefwindows.  That bug isn't going to be fixed though, is it?  While this bug could be fixed with a couple of lines of javascript.

The symptoms are also different.  Bug 161711 means that arbitrary code that chooses (or forgets!) not to flush a changed preference might lose the change after a crash, which is unfortunate but could be considered "just the way it is".  This bug means that a prefwindow, an official API, might lose a preference change after a crash, which is just bad and without any practical workaround.


5 years ago
Component: Preferences: Backend → Preferences
Product: Core → Firefox
You need to log in before you can comment on or make changes to this bug.