The use of prefs to disable new features

Marco Bonardo mbonardo at
Tue Dec 22 12:17:18 UTC 2015

I just wanted to start a brief discussion about our use of prefs to quickly
enable/disable new features.

The problem I'm seeing happened multiple times, some recent examples are
one-off searchbar UI and unified complete, but I can definitely find more
examples in the past.
Basically when we use prefs to enable new features, we leave a UI access to
the user to disable it. It's true that it's hidden in about:config, but
that's not really enough.

What usually happens is that someone looks for the pref, posts the
"solution" on forums/reddit/articles on the web. Anyone that is surprised
by the change goes can easily find that "solution" on the Web and can apply
it easily (usually it's a brief 4 steps).
When we remove the pref cause the feature is stabilized enough and has hit
at least one release, all those users hit again the change they didn't
understand first, and get angry for the second time.
Moreover users won't file enhancement requests to fulfill their needs,
cause they can easily revert to something we are about to remove.

Very often the are other better alternative solutions (add-ons or
userchrome hacks) but at this point the user is angry to us, cause to him
looks like we forced the same change twice, plus we removed the option he
was using. It's easy to lose a user when you disappoint him thrice in a row.

I was wondering if we could evaluate alternatives that are not easily
flippable through the UI. This is not about removing customization or user
options, rather to avoid disappointing users multiple times for no good

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list