On 6/19/2014 10:00 PM, Masayuki Nakano wrote:
I'm looking for guidelines for naming preferences. However, I've never
found it yet. I guess that there is no guidelines.
That is correct. The current rule is to use common sense and coordinate
with the module owner.
If the pref will be exposed in the UI preferences, you should also
coordinate with UX design to make sure that we can express the
preference in the UI in a useful way.
When I work on some bugs, I need to add a new option for a pref
switchable behavior, e.g., if we need to add a new option to a feature
and the new one isn't enabled in default settings, it's better to add
new pref for the additional option in some cases.
Here are the reasons we should be adding prefs:
A. We actually want to expose the option in the preference UI (needs UX
review)
B. To enable release drivers to turn it off easily if there is a problem
found
C. a feature is experimental and we want to limit it to certain channels
while it is stabilized
D. To enable other internal usage: e.g. A/B testing via telemetry
experiments
I believe that we should not be adding hidden prefs just because a small
minority of people might want a feature, but we've decided not to expose
it in the browser preferences. Those kinds of choices should be made by
installing Firefox extensions. In particular, using an extension instead
of a hidden pref setting means that we will see the non-default choice
in various metrics like about:support, telemetry/FHR, and that Firefox
safe mode reverts the setting in case of problems.
In any case, this probably doesn't have much to do with naming ;-)
I think that a pref which enables/disables a feature should end with
|.enabled|. Then, above example becomes:
> |foo.a_feature_name.enabled|
> |foo.a_feature_name.disabled_on_some_environments|
If it's a boolean feature, I think the common pattern is to used
foo.feature.enabled. e.g. app.update.enabled or dom.ipc.plugins.enabled.
This sounds reasonable to document.
The can be defined by a formula:
<general-group>.(<sub-group>.)*<target-feature>.<state>
The <state> shouldn't be omitted.
I think this rule is too general. Let's stick with the "enabled" rule
for now.
And also, <sub-group> should be used as far as possible.
Why? Flat names seem quite reasonable.
nsXPLookAndFeel observes every pref. For doing that, it observes *all*
prefs under |ui.|.
http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#430
And the observer uses 3 loops for retrieving the pref cache from the
arrays.
http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#388
If somebody changes a pref under |ui.| at runtime, every change causes
running this expensive method.
How expensive? Pref changes at runtime are in quite unusual after
startup, and I don't think we should necessarily optimize for this case.
On the other hand, I do think it makes sense to consider the
implementation when defining a pref namespace: if you're observing an
overly broad branch and there's an easy way to design that away, that
sounds reasonable.
For example, some metrics/colors which can be retrieved with
LookAndFeel class can be override by hidden prefs. The most hidden
prefs are named as |ui.<metricsName>| or |ui.<colorName>|.
http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#26
# Anyway, if it's allowed, we should rename the pref names referred
from nxXPLookAndFeel even though customized users will need to set
them again.
Do we need this code at all? This sounds like the kind of code that
would be better to remove entirely.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
