<p dir="ltr">Great question! I wonder if a relatively easy option (technology-wise) would be to use a build-time flag on AppConstants or a similar but unfrozen jsm? Then tests and JS can still toggle the option, it's still easy to make it depend on nightly/early-beta/whatever,  but it's not user-visible.</p>
<p dir="ltr">I'd be hesitant to keep using prefs and build a general-purpose hiding mechanism into about:configuration because I'd be worried it would be abused.</p>
<p dir="ltr">Gijs</p>
<div class="gmail_quote">On 22 Dec 2015 1:18 pm, "Marco Bonardo" <<a href="mailto:mbonardo@mozilla.com">mbonardo@mozilla.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>I just wanted to start a brief discussion about our use of prefs to quickly enable/disable new features.<br><br></div>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.<br></div>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.<br><br></div>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).<br></div>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.<br></div><div>Moreover users won't file enhancement requests to fulfill their needs, cause they can easily revert to something we are about to remove.<br><br></div><div>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.<br><br></div><div>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 reasons.<br><br></div><div>Cheers,<br></div><div>Marco<br></div></div>
<br>_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br></blockquote></div>