On 3/20/14, 10:38 AM, Irving Reid wrote:
Looking into some odd exceptions in the Addon Manager (bug 985998), I
found that the behaviour of the Preference service is:
a) We infer the type of a preference from the data read in from prefs.js
(see e.g.
http://dxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefread.cpp#288)
b) When we try to get or set the pref, we return NS_ERROR_UNEXPECTED if
the type of the set*Pref() call doesn't match the inferred type
(http://dxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefapi.cpp#764)
For unknown reasons, internal bookkeeping prefs used by AddonManager and
XPIProvider are set to values of the wrong type on some Firefox
profiles, and are now stuck that way. I can write wrapper code on these
calls to catch the error and clear the broken preference, but I wonder
if it would be better to change set*Pref() to force the preference to
the intended type.
In a way we're dancing around competing footguns here - do we protect
against bad code trying to break our preferences by setting a value to
the wrong type, or do we protect against a broken preference messing up
our code because we can't recover from a wrong type?
I use Preferences.jsm, which uses the JS type to call the appropriate
set*Pref() and calls getPrefType() as part of get() so we never have a
type mismatch on retrieve. "It just works." It even manages observer
notifications for you. Aside from a minimal performance overhead (which
I doubt is even measurable), I'm not sure why people would want to use
the XPCOM interfaces over Preferences.jsm.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
