<div dir="ltr"><div><div><div>Two things to keep in mind when thinking about what to do with prefs:<br><br></div>1. Disabling features at runtime has been a useful solution to get users out of a jam when a new feature misbehaved on their system. The most obvious example in the past year was when we rolled out OMTC.<br></div>2. Enterprise admins (typically but not always ESR based) disable features in their rollouts. These users are looking for more flexibility in this regard, not less.<br><br></div>Lawrence<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 22, 2015 at 11:53 AM, »Q« <span dir="ltr"><<a href="mailto:boxcars@gmx.net" target="_blank">boxcars@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 22 Dec 2015 15:17:29 +0100<br>
Marco Bonardo <<a href="mailto:mbonardo-4eJtQOnFJqFBDgjK7y7TUQ@public.gmane.org">mbonardo-4eJtQOnFJqFBDgjK7y7TUQ@public.gmane.org</a>> wrote:<br>
<br>
> Naming the pref "temporary" would solve a part of the problem, but I<br>
> think it still has some downsides:<br>
> 1. non-tech could just keep following the tutorials and really not<br>
> care about the pref name<br>
> 2. temporary could also be interpreted as if the feature is enabled<br>
> temporarily, while we are trying to enforce the opposite<br>
> 3. non-english users could not understand what temporary means in this<br>
> context<br>
><br>
> I was thinking something more similar to what Gijs suggested, so a<br>
> code flag, not yet sure in which form though.<br>
<br>
</div></div>IME, by the time the pref stops working, there's often an extension<br>
which gets the disgruntled users what they want.  A code flag would put<br>
them in the position of not having any way (short of patching and<br>
building themselves) to get what they want for some period of time<br>
(until an extension comes along).  It has the advantage of not<br>
hitting them multiple times but the disadvantage of hitting them much<br>
harder once, maybe hard enough for them to abandon Fx or revert to an<br>
older, less secure version.<br>
<br>
If the pref-naming idea is used, maybe instead of having<br>
"enable.the.new.temporary-pref", having<br>
"disable.the.old-feature.deprecated-pref" would help.  It makes the<br>
logic more convoluted, but makes it clearer that both the old feature<br>
and the pref are going away.  Non-techies might not notice, but<br>
hopefully some of the techies writing recipes for them would notice and<br>
include that info in their tutorials.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>