On 2014-03-20 1:50 PM, Gregory Szorc wrote:
On 3/20/14, 10:38 AM, Irving Reid wrote:
...
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.
Preferences.jsm is great, but it doesn't solve this particular problem;
once a wrong-type value gets into prefs.js we don't have an easy way to
fix it.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
