Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider support for permanentPrivateMode #469

Open
pwaring opened this issue Apr 28, 2017 · 33 comments

Comments

Projects
None yet
9 participants
@pwaring
Copy link

commented Apr 28, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Apr 28, 2017

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

@pwaring

This comment has been minimized.

Copy link
Author

commented Apr 28, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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

Thanks

@jonathanKingston

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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

@jonathanKingston

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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

@pwaring

This comment has been minimized.

Copy link
Author

commented Apr 28, 2017

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	aushelper@mozilla.org
Containers Experiment	2.2.0	true	@testpilot-containers
Multi-process staged rollout	1.14	true	e10srollout@mozilla.org
Pocket	1.0.5	true	firefox@getpocket.com
Test Pilot	1.1.2-dev-f3fe9bf	true	@testpilot-addon
Web Compat	1.0	true	webcompat@mozilla.org

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

@jonathanKingston

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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):
selection_612

@jonathanKingston jonathanKingston changed the title Containers stopped working in Firefox 53.0 Consider support for permenantPrivateMode Apr 28, 2017

@pwaring

This comment has been minimized.

Copy link
Author

commented Apr 28, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

@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

This comment has been minimized.

Copy link
Author

commented Apr 28, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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

This comment has been minimized.

Copy link
Author

commented May 23, 2017

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

This comment has been minimized.

Copy link
Member

commented May 26, 2017

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

@pwaring

This comment has been minimized.

Copy link
Author

commented May 26, 2017

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

This comment has been minimized.

Copy link
Member

commented May 26, 2017

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

@pwaring

This comment has been minimized.

Copy link
Author

commented May 26, 2017

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

This comment has been minimized.

Copy link
Member

commented May 26, 2017

@pwaring

This comment has been minimized.

Copy link
Author

commented May 26, 2017

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

This comment has been minimized.

Copy link
Member

commented May 26, 2017

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

This comment has been minimized.

Copy link
Author

commented May 26, 2017

Yes, hence the title of the issue...

@yareckon

This comment has been minimized.

Copy link

commented May 28, 2017

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

@jonathanKingston

This comment has been minimized.

Copy link
Member

commented May 29, 2017

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

This comment has been minimized.

Copy link
Author

commented Jun 30, 2017

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 pwaring changed the title Consider support for permenantPrivateMode Consider support for permanentPrivateMode Jun 30, 2017

@pwaring

This comment has been minimized.

Copy link
Author

commented Nov 23, 2017

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

@groovecoder groovecoder removed the bug label Dec 5, 2017

@adisandro

This comment has been minimized.

Copy link

commented Jan 10, 2018

Voting for this feature to be implemented.

@wiktorn

This comment has been minimized.

Copy link

commented Jun 2, 2018

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

This comment has been minimized.

Copy link
Author

commented Jun 12, 2018

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

@voidstarstar

This comment has been minimized.

Copy link

commented Feb 14, 2019

@wiktorn @pwaring I think you're expected to click 👍 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: #1164 (comment)

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

This comment has been minimized.

Copy link

commented May 4, 2019

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

This comment has been minimized.

Copy link

commented May 4, 2019

@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

This comment has been minimized.

Copy link
Author

commented May 6, 2019

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

This comment has been minimized.

Copy link

commented Jun 5, 2019

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

This comment has been minimized.

Copy link

commented Jun 27, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.