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?
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
