On 3/20/14, 10:50 AM, Gregory Szorc wrote:
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.
And to more directly answer your question about type mismatch leading to
bustage, I try to write initialization code that looks for bad values.
e.g.
https://hg.mozilla.org/mozilla-central/file/cf485c48b52f/services/healthreport/healthreporter.jsm#l217.
The type handling in that code is behind getDatePref(). But it shouldn't
be too difficult to cobble together something that verifies types match
and reset if not. I reckon someone could add "schema" support to
Preferences.jsm. That might be a nifty way of shoehorning type
validation into an XPCOM interface that likely won't change any time soon.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
