<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>