Currently we have many confused users where to access containers which are enabled in Nightly by default but not in beta and stable. My proposal it to allow the user to enable them in about:preferences when in beta/stable. There aren't any implications here other that they will then need to manually enable them. To clarify: this itself won't enable container tabs themselves. The user will still need to check the box in about:preferences.

Comment on attachment 8911473 [details] Bug 1402608 - Enable containers ui pref for non nightly users. https://reviewboard.mozilla.org/r/182934/#review188152 Redirecting to Dave because this basically needs sign-off that the feature is ready to ship on beta/release (somewhat softened by its being opt-in, but even then), and I don't know who the right person is to make that call, hopefully Dave does. The code change as being a perf flip is trivial, and I'm fine with that, but that's not really what you need here. (In reply to Jonathan Kingston [:jkt] from comment #0) > Currently we have many confused users where to access containers which are > enabled in Nightly by default but not in beta and stable. I must admit I am confused by this. Why are users moving from nightly to beta/stable, and why are such users confused that things are different on beta/stable? Containers isn't exactly the only feature that works differently on/off nightly. Also, if I were making this decision (which I'm not!) I would like to understand better how you came to the conclusion that "many" users feel this way (ie is there data to back up that assertion? how many is many?). In general, I thought that the 'containers' terminology wasn't final, and I think some of the UI/UX may still need review (maybe this happened since it got implemented and I missed it - please clarify if so). While we worked on some of the UI in nightly, a lot of concerns were assuaged with "this is experimental and we won't ship it like this, we'll iterate if people find it useful". It's quite possible I've just been out of the loop, but if we are now shipping this I think the groundwork / experimentation / telemetry analysis / user studies / design work etc. that was foundational to that decision would normally be linked in the bug or its dep tree, and I don't see that here (apologies if I've missed it!). Related, how does this (not?) affect the test pilot containers add-on?

> Redirecting to Dave because this basically needs sign-off that the feature is ready to ship on beta/release Thats great thanks, I just checked the last reviewer of those prefs is all > Why are users moving from nightly to beta/stable > I would like to understand better how you came to the conclusion that "many" users feel this way This isn't anecdotal but I also don't have data to quantify "many" of users who have complained about being confused about how they enable containers given that we have had: A shield study, Test Pilot, Nightly Containers users have reported feeling lost about how they even enable them. The reports we had through discourse, twitter, email etc were all users who had read blog posts etc and had been confused how they could turn it on. Developers also use multiple version too. I can try and dig out some of these reports however I don't have anything concrete in numbers at the moment. We also have shipped for a long time many other experiences that aren't ready to be default (Tracking protection or the ctrl+tab changes) I don't see how this is much different. > In general, I thought that the 'containers' terminology wasn't final "Container Tabs" is what has been communicated in the browser along with users not being confused with the Test Pilot experiment and it's naming. The addon itself has since graduated Test Pilot to land in AMO for users to download there along with many other container based addons (https://addons.mozilla.org/en-US/firefox/collections/jkt/container-addons/) that probably account for ~20k of users as of it's launch just over a week ago: https://blog.mozilla.org/firefox/introducing-firefox-multi-account-containers/ We would need to do some form of custom query to work out MAU or DAU based on unique pings from: CONTAINER_USED or similar. > I think the groundwork / experimentation / telemetry analysis / user studies / design work etc. that was foundational to that decision would normally be linked in the bug or its dep tree, and I don't see that here (apologies if I've missed it!). :grovecoder might be able to point to more concrete research here. > Related, how does this (not?) affect the test pilot containers add-on? It doesn't hugely other than this has launched onto AMO, the addon we made there just made it a little easier to manage some container features.

Having spoken to others regarding this bug, I think we want to hold off on this until we get further affirmation of our addon on AMO. I'm going to close this for the time being.