Multi-account-containers: Consider support for permanentPrivateMode

[pwaring]

I've been using the Containers feature for a few weeks in Firefox 52 (using the userContext options in about:config). It worked fine until Firefox auto-updated to version 53 -- now File -> New Container Tab is greyed out and a long-click on the new tab button no longer gives me the container options.

This has happened in Windows 8, Ubuntu 16.10 and macOS 10.12.4 so it appears to be a generic issue rather than platform-specific. The functionality was definitely working in 52.0.2 on all platforms and stopped working in 53.0 so appears to be a regression bug.

The relevant about:config settings are:

• privacy.userContext.enabled: User set to true
• privacy.userContext.longPressBehavior: Kept as default of 0 (this option didn't exist when I originally enabled containers)
• privacy.userContext.ui.enabled: User set to true
• privacy.usercontext.about_newtab_segregation.enabled: User set to true

[bakulf]

Does it happen also if you install the test-pilot container addon?

[pwaring]

I've just installed test-pilot and restarted Firefox. The menu item is still disabled and long-clicking the new tab icon doesn't work.

[jonathanKingston]

@pwaring could you paste the value of: "browser.privatebrowsing.autostart" and also the extensions you have in about:support?

Thanks

[jonathanKingston]

privacy.userContext.ui.enabled should be set to false also

[jonathanKingston]

@pwaring the long press should be replaced with a hover menu on the + icon instead in the test pilot.

[pwaring]

browser.privatebrowsing.autostart is set to true (I haven't set this directly but I assume it's a consequence of having Firefox start in private browsing mode by default).

privacy.userContext.ui.enabled is now false (I didn't change it, I assume test-pilot did).

If I hover over the + icon I get a tooltip saying 'Open a new tab (Ctrl + T)'.

The list from about:support is:

Application Update Service Helper   2.0 true    [email protected]
Containers Experiment   2.2.0   true    @testpilot-containers
Multi-process staged rollout    1.14    true    [email protected]
Pocket  1.0.5   true    [email protected]
Test Pilot  1.1.2-dev-f3fe9bf   true    @testpilot-addon
Web Compat  1.0 true    [email protected]

That's from the Windows Firefox, the Linux one also has NoScript.

[jonathanKingston]

browser.privatebrowsing.autostart is set to true (I haven't set this directly but I assume it's a consequence of having Firefox start in private browsing mode by default).

This is the problem, currently we don't support that. We should have put a warning in about this. However it's actually so infrequently used you are the first to report it.

The following setup gets you 90% there instead (this is what I use):

[pwaring]

What I don't understand though is why it stopped working in 53 - I had the same settings in 52.02 so containers did work with private browsing on by default. Can you not revert whatever change broke the functionality?

[jonathanKingston]

@pwaring what was your setup in 52, were you using the test pilot experiment or the preference setup?

I made the assignment feature depend on private mode being off, however no other changes were made to depend on this setting so it shouldn't have made a difference. Did you change the setting and not restart your browser perhaps?

The preference only version of containers hasn't ever worked for this mode (I have a patch to put in core firefox still waiting to land).

[pwaring]

I was using the preference in 52 - I only installed the test pilot experiment because @bakulf asked me to. In fact checking my Twitter history it looks like you were the person who told me how to use preferences. :)

I shutdown my PC every night and I've been using this functionality since 5th April so it's not a case of changing settings and forgetting to restart.

The preference only version of containers hasn't ever worked for this mode (I have a patch to put in core firefox still waiting to land).

That doesn't tally with my experience. All my Firefox instances use private browsing by default and containers were working in all of them until 53 landed.

[jonathanKingston]

In fact checking my Twitter history it looks like you were the person who told me how to use preferences. :)

Heh yeah I thought I recognised you :bowtie:

That doesn't tally with my experience. All my Firefox instances use private browsing by default and containers were working in all of them until 53 landed.

Yeah this comment was specific to this experiment only... I didn't think it was our extension causing this as there isn't much code checking it.

As for 53, I can only think we had bugs that showed some of these menu items in private mode when they shouldn't have been shown. The reason this bug exists is due to us hiding containers features when users are in normal private mode. However this means users like yourself have a hidden menu.

@bakulf and @kjozwiak do you know of any instances in 53 Firefox where we fixed a private menu that shouldn't have been shown?

@pwaring I can look into getting my core patch landed to enable containers again in alwaysPrivateMode which would likely give you these menus back in 55. Unfortunately small regressions like this especially for not core functionality of Firefox wouldn't be able to be backed out.

[pwaring]

I don't know if something has changed but I can now get a container by clicking the Containers icon on the menu in 53.03. It's not quite as convenient as the new tab button and it insists on telling me about containers every time I restart Firefox, but I can at least get at the functionality.

[jonathanKingston]

@pwaring so you think this can be closed? We have #490 too if you could try that STR that would be great.

[pwaring]

I would prefer that the functionality was restored to what it was in 52.0, since clicking on the new tab icon was more convenient and user-friendly than having to click through 3 pop-ups on the container menu.

[jonathanKingston]

@pwaring this is still the experience in Firefox itself with the containers preference privacy.userContext.enabled set to true in about:config

[pwaring]

I'm not sure what you mean by that. If I try using 53.0.2 with the various settings in about:config then I can't create a new container tab unless I install the test pilot add-on, and then only by going through three reminders each time I restart my browser.

[jonathanKingston]

Without the test pilot you can add/remove containers in about:preferences
under privacy.

On Fri, 26 May 2017, 11:38 Paul Waring, [e-mail] wrote:

I'm not sure what you mean by that. If I try using 53.0.2 with the various
settings in about:config then I can't create a new container tab unless I
install the test pilot add-on, and then only by going through three
reminders each time I restart my browser.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/testpilot-containers/issues/469#issuecomment-304249695,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUsLOSU0H2-c0rWp2jB-5qpxhqarf-pks5r9qujgaJpZM4NLO3v
.

[pwaring]

Yes, I can change the list of containers. What I can't do without the Test Pilot add-on is open a new tab in a given container. There is no long-click option on the New Tab icon and the New Container Tab option in the File menu is greyed out.

[groovecoder]

There is no long-click option on the New Tab icon and the New Container Tab option in the File menu is greyed out.

Are you in a Private Browsing window by any chance?

[pwaring]

Yes, hence the title of the issue...

[yareckon]

Just adding that @pwaring is not the only one wanting this feature to work correctly in Permanent Private Browsing Mode.

[jonathanKingston]

The comments in #548 suggest that this was a change in Firefox and the time difference is release channels perhaps? I suspect it was a 53 change that did this and outside what we can control in the experiment.

[pwaring]

Update: I can no longer open new container tabs at all (with the add-on), as of 54.x (I think - I'm on 54.0.1). If I click the container link and then choose a container, nothing happens.

I can still add/edit existing containers but without the ability to use them this feature is unusable.

[pwaring]

This still seems to be broken in Quantum (57.0) - the New Container Tab is still greyed out.

[adisandro]

Voting for this feature to be implemented.

[wiktorn]

I also vote for this feature. Is there any other way to vote? Can't see anywhere documented what's the best way to vote for feature.

[pwaring]

I can't see any way to vote either - obviously as the original reporter I would like this to be fixed. :)

[voidstarstar]

@wiktorn @pwaring I think you're expected to click :+1: on the original post in order to "vote" for it.

When in a Private Browsing window, if I click the button to create a new tab in a container, I get the following error message:
Error: Illegal to set non-private cookieStoreId in a private window

A similar experience appears to be noted here: https://github.com/mozilla/multi-account-containers/issues/1164#issuecomment-376662522

Is this related to the new contextIdentities API? It sounds like MAC is attempting to create a new non-private cookieStoreId from within a private window. Is it possible to create more than one private cookieStoreId?

If there's a default non-private container, I wonder if there should also be a default private container.

[voidstarstar]

It looks like this depends on this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1320757

This issue specifically talks about permanent private browsing mode, but I see no reason why this shouldn't be permissible for regular private browsing mode too. Most use cases for permanent should also apply to non-permanent.

Non-permanent private browsing example:
A user has 3 websites (A, B, and C) that they visit, but does not want any of them sharing a session, so they'd like to use containers. They open Website A in a normal non-private window because they want to save history. They press Ctrl+p and open Websites B and C in a private browsing window because they don't want them saving history. Currently there's no way for B and C to use private browsing while not sharing the same session.

[voidstarstar]

@jonathanKingston I just realized that you were the author of a patch for this. Maybe I'm misunderstanding your patch, but it looks like it is trying to allow containers to work in private windows when permanentPrivateBrowsing is enabled but not work in private windows when permanentPrivateBrowsing is disabled. Is there a reason why containers shouldn't just be enabled universally? You stated:

We disabled containers for when in private mode due to the confusion caused by having both personal container open and private personal container open.

So is the reason for this limitation simply to prevent a user from seeing the same container being used in both a private and non-private window? If so, this sounds like a UX issue rather than a technical one. Instead of a blanket ban of containers for all private windows, I can think of 2 possible solutions:

1. Do not allow the same container to be simultaneously used in both a private and non-private window. If a user has a private and non-private window open, they must use 2 containers that each have 1 session. There would be a default normal container and a default private container.
2. Allow the same container to be simultaneously used in both a private and non-private window, but clearly differentiate between them with a visual indicator (e.g. a purple mask). If a user has a private and non-private window open, they can have 1 container that uses 2 sessions. There would only need to be a single default container.

I suspect that option 1 is more in line with user expectations, but option 2 is what you were thinking of when you disabled this feature. In option 1, private browsing mode could be implemented as just a "type" of container. All containers would have a flag that designates them as either "normal" or "private". Then if the user enables permanentPrivateBrowsing, it would just open the default private container and just prevent "normal" containers from running while still permitting "private" ones. I think this approach would give users the most freedom while still making the feature intuitive to use.

[pwaring]

I think there are two different use cases for private browsing and containers, albeit with a bit of overlap. For example, the biggest selling point of containers to me is not to do with privacy or isolating sites such as Facebook, but the ability to have simultaneous sessions with the same website - I think containers are the only way to achieve that within the same browser.

[LoZio]

Adding to the voters here! I just switched to Firefox from Chrome just to use the containers feature. I usually have no history recorded and discovered the feature is not available.
On my part, I see more confusion installing an extensione (fb containers) or reading docs about containers and then not having the way to use it without apparent reason, than having them both working. At least we need some type of message telling you what's happening, but I would greatly prefer to have the feature.

[voidstarstar]

It should be noted that starting in Firefox 67, extensions will be disabled in private browsing by default. This means that any potential confusion caused by private browsing would have required a user to manually enable this extension for private browsing. Since a user now explicitly needs to enable this, I think the risk of confusion is greatly diminished.

[Utini2000]

I also vote for this. I use firefox at several clients/PC's in permanent private mode and it's sad to see that this extension doesn't work in such an environment.
Ofcourse I enabled the extension to work in private mode.

[opusforlife2]

First of all, with all the similar terminology floating around here, I'm not even sure this is the issue I need to be commenting on. Can someone confirm? I have "Use custom settings for history" selected, and "Always use private browsing mode" enabled under that.

If I'm at the right place, then I add my vote. I find it a bit strange that this extension wasn't introduced with private browsing support from the start. A user who is privacy conscious to the level of using private browsing permanently would definitely want to have container support.

[pwaring]

@opusforlife2 Yes, if you have those settings ("Always use private browsing mode") then you will be affected by this issue.