33683 - Need a way to tell when prefs are initialized

Status: VERIFIED INVALID

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

Description

[Akkana Peck]

If you call the pref service too early (e.g. before the profile window has been
shown), and try to get a pref which is in the user's prefs.js but not in all.js,
you get NS_ERROR_UNEXPECTED from the prefs service routine (e.g. GetIntPref)
instead of NS_ERROR_UNINITIALIZED.

I need a way of distinguishing these two cases -- the "it might be there, but I
don't know because I haven't read user prefs yet" vs. "I don't know about that
pref and never will".  (I need this because I need to initialize a pref used for
the widget library, and the profile manager uses the widget library before it
selects a user.)

Shaver said he had also run into this problem.

Comment 1

[Mike Shaver (:shaver emeritus)]

I just bet this has profile-startup interactions, so welcome to Seth.  Maybe we
need a prefs-loaded notification?

(We could make up a magic pref name, like '__mozilla_user_prefs_loaded__' and
then akk and I could just install listeners for it.  A bit hacky, but not
grotesquely so.)

Comment 2

[Alec Flett]

set a prefs callback on the pref you're interested in - when the user's prefs
get loaded, you'll be notified.

marking invalid because I assume this is what you need.

we do this for the DPI setting in GFX, since choosing a profile brings up UI
before the user's prefs are loaded - bringing up the UI triggers a read of a
pref, but when the user's prefs are different, the callback fires and updates
the pref in the device context.

Comment 3

[Mike Shaver (:shaver emeritus)]

You'll only get that notification if the user actually has the pref, though,
right?

The problem in my case was that I was wiring up a selection observer for
autocopy, and I wanted to have default behaviour if no pref was set.  I have no
way of ever knowing that it's time to do that, unless I get some sort of
notification for prefs-loaded that's different from
value-for-this-pref-explicitly-set.

Comment 4

[Alec Flett]

right.
I guess what you need to do is:
a) put a "default behavior" pref in all.js or some similar pref file
b) put a callback on this pref

What will happen is this:
First, profile manager case:
1) when the profile manager comes up, the pref you'll get will be the one in
all.js (or wherever you put it) - i.e. no NS_ERROR_* returned from GetBoolPref
2) when a profile is selected, prefs will be loaded. if the pref loaded by the
user is different than the pref, you'll get a callback saying that the pref
changed. At this point you can do a GetBoolPref and get the user value of the
pref. If the pref does not change, you get no callback, but that just means they
have the same value as the default pref.

in the no profile manager case, you'll probably be initialized after prefs have
already been loaded. In that case you'll just get the right value..

the more I think about this it sounds like you're just not putting a default
pref in all.js

Comment 5

[Mike Shaver (:shaver emeritus)]

So is our policy then that you need to put entries in all.js for sane prefs
behaviour?  If so, is there a way to alter all.js for components that are
installed separate from the build?

Comment 6

[Alec Flett]

oh, yes, I assumed you knew that. :)

so what you can do if you have pref for stuff not in the core mozilla is to make
a default pref file in the same form as all.js, and deposit it in
$MOZILLA_HOME/defaults/pref/

when the prefservice starts up, it reads in all the default prefs from the JS
files in this directory.
you'll notice that there is a mailnews.js, editor.js, and so forth.

Comment 7

[sairuh (rarely reading bugmail)]

verif.