On 2014/06/30 22:51, Masayuki Nakano wrote:
Hi, I wrote a draft of the guideline in MDN roughly.
I hope a lot of developers discuss the rules and improve this draft!
Oops, the draft is here. Sorry for the spam.
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Preferences
Thanks in advance.
On 2014/06/30 16:24, Masayuki Nakano wrote:
Thank you for the reply, but sorry for the delay.
On 2014/06/20 23:25, Benjamin Smedberg wrote:
On 6/19/2014 10:00 PM, Masayuki Nakano wrote:
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 ;-)
There are two hidden prefs.
One is not in UI but shown in the list of about:config. The other is not
in both UI and about:config. I.g., there is a checking the pref value
code but not included in all.js and other similar files.
I think that the former is important for some minority users. Yes, they
must be minority but their reason to use Firefox must be the
customizability by this kind of hidden prefs. And such minority users
who can customize about:config may help their friends and family to use
our product. Therefore, I believe this is important for keeping market
share.
The latter should be used for developing or automated tests.
And also, <sub-group> should be used as far as possible.
Why? Flat names seem quite reasonable.
The reason is for the runtime cost of observing brunches as I mentioned
below.
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.
Although, I don't measure it actually. But if somebody adds a pref under
|ui.| and it may be updated from UI, it may cause short hangup at
changing it. This is really bad UX and automated tests must not be able
to detect this problem.
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.
At least I really need this because these prefs can emulate other
environments on each environment. E.g., on Windows, we can test Mac OS X
style scrollbar. This is very important to work on around XUL.
# FYI: These prefs are not listed in about:config.
--
Masayuki Nakano <masay...@d-toybox.com>
Manager, Internationalization, Mozilla Japan.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
