Choice of which container to use when visiting website

[eoghanmurray]

Containers are a great idea, but IMO the implementation just hasn't cracked it yet and there needs to be some back-to-basics work listing the use-cases.

Here's one problem I have:
I've got a website (a webhosting company) that I've got multiple accounts with and that I want to manage with containers so that I can maintain 2 sessions open to e.g. cross-correlate domains or whatever.

The problem I have is that I can't use the 'Always open in [X container]' functionality as I've got 2 containers that handle the website.

Prior to containers, my normal browsing habit would be to type in the url of the webhosting company, and then choose which account to log in with.
This flow is very much interrupted by containers, as there is no hint given that I might already be logged in to the webhost (in an already open tab of one of the 2 containers).
What usually happens is that I open a new tab, type in the URL, go to log in and then realize 'oh I need to open this website in a container'. At which point I have to hunt through my containers to remember which one to use, and then open a new container tab, transfer the URL over to that new container and then close the original tab.

Which is to say, containers have just made my life harder, not easier.
What is easier is to use e.g. Firefox for account #1 and Chromium for account #2.
So that is the thing containers are competing with, and it needs to be easier to do in containers than in the above scenario.

So point 1: Firefox should remember that a container has been used to log in to a website (presence of cookies maybe?) and auto-suggest that container when an attempt is made to visit a website (when you are in the default/null container). I shouldn't have to click 'always open in X'... if I've ever opened a website in X container, then that should be enough to make the suggestion

Point 2: if a website has been logged in using multiple containers, using different login accounts, then a list of those containers should be presented/suggested to the user when attempting to visit that website from the null container.

So the main point is that containers should arise organically via the process of logging into an account on a website; this should be the primary use-case (managing accounts & keeping accounts separate). From this basis, other use-cases can be approached, some ideas:

• paranoid-strict handling of cookies in the default container
• warning when loading a website in the wrong container prior to loading it
• auto-creation of per-website containers when you create an account on a website
• joining the above per-website containers into categories, e.g. 'Work'

[mikepurvis]

Agree completely. The system should be able to tell which of my preexisting containers has a session cookie for website X and automatically use that one. And if it's only one, one of the accept buttons should just be "Always Use".

[eoghanmurray]

What actually has been happening is that I open a new tab, type in a URL of a website that I've an account with; it doesn't recognize my 'remember me' as the previous login to that website was from within a container, so instead of trying to mess with the container, I go back to Chrome, as I know for definite that that will already have the 'remember me' session open.

[grnassar]

I almost commented here before creating my issue ticket, as I thought they were related:
#1494

Do your containers tend to represent groups of sites that you're working with simultaneously? (so, you mention the website you open the account with was in a particular container, but when you open a new tab it is of course not assigned to that container -- are the other tabs in that window usually also within that container?)

I ask because I think that's a very common use case, and because of that being able to assign a container not just to a tab, but optionally also to an entire window, would neatly solve the vast majority of instances where that comes up. (This wouldn't limit the ability to have a tab from a different container in that window as well -- it would just change the default behavior for any new or manually entered tags.)

So in your example, if my guess was right and you had the majority of tabs in that window already opened to a specific container, the idea would be that you would assign that window to the container; when you then open a new tab and go to that site related to the work you're doing elsewhere in that window, it would open in the correct container and automatically recognize your 'remember me' information.

If you guys think that would be a useful change insofar as your issue goes, maybe leave a note in that issue thread about it? I'm not sure how often these are listened to (I'm sure the Mozilla guys keep very busy!), but I imagine it's possible that if something has a number of comments perhaps it gets more attention. Thanks!

[mathstuf]

This comment contains mainly thoughts on this feature, so take it closer to a "musing" level of severity.

Some further behaviors which could be nice-to-have:

• if opening a new tab from a container with an association with the website, make it "sticky" (don't ask if I want to use a different container)
• the ability to make some containers "jails" (never leaves when opening a new tab from this container); my thought in conjunction with Temporary Containers so that sites don't "escape" without an explicit "reopen in container" action
• designate a container as "default for any site without an associated container"

One nice way this could be done is to allow multiple containers to claim "open this site in this container" flag (which would likely need a rename/relabel). When asking what container to open a site in that has an association:

• use current container
• use associated container X
• use associated container Y

[mathstuf]

Actually, if the two buttons in the page that asks what container you want to use could each be dropdowns. The right one would have every container that is "associated" with the target URL. The left one would have the current container (or "no container" if the current container is in the right button list) as the default one and be able to dropdown into a selector for all other containers.

[eoghanmurray]

@grnassar the idea of a default container per Window is a good one, however I think you may have missed the key insight from my comment, which I'll try to restate here:

The main thing I do in a browser is 'browse websites'. It is not, and never will or should be 'think about or interact with containers'. So containers should be layered on top of normal browsing, and not something you have to do prior to browsing (in your case, that would be to open up a new window with the right container).

---

Further example:

So browsing to new websites should (by-default from a security concern) be kept separate in their own container. If you browse to Facebook.com and log in, that is Facebook-A container, with that container remembering your login details.

If you visit a 3rd party website 'facebook-example-survey.com', it will by default get it's own container. If this embeds a Facebook iframe, then it shouldn't, by default, identify you as the original FB user, and either the iframe is blocked, or it asks you whether you wish to join the 'facebook-example-survey.com' container to the 'Facebook-A' container (or to create a new blank Facebook container).

If you want to have 2 separate accounts on Facebook in the same browser, you can use a special function to open up a new facebook.com container 'Facebook-B' (an uncommon but important usecase). Then any initiation of a browsing context to facebook.com (bookmark, or type in a url) should ask which container you actually want, and any embedded iframe on a new website should ask which Facebook container you wish to 'join' the current container to.

If you've previously associated 'facebook-example-survey.com' with 'Facebook-A', and you want to redo the survey for 'Facebook-B' then you'd need to use that special function again to open up a new 'facebook-example-survey.com' container, which will then have a blocked iframe which will further provide a prompt as to whether you want to open it with 'Facebook-A' or 'Facebook-B' or 'new Facebook'.

(It wouldn't only be iframes that would trigger the prompt, but also things like using 3rd party login, cross-domain websockets or whatever)

[julKali]

This is also very annoying when using Google Cloud with multiple accounts. E.g. I have my main account that I use all the time for services like drive or docs. So, I set these sites to be opened with my main account by default. But every now and then, I need to open the drive of another account but it gets impossible with the open by default feature enabled. I have to disable the default setting first and only then I can access the site with another account. Extremely tedious!
I think a very basic but drastic enhancement would be to add the possibility to "overwrite" the default behaviour with reopen. So, for example, if I open drive.google.com then it should open it with my main account. So far, so good. But when I then right click on the tab and select Reopen in Container, I should be able to overwrite the behaviour for this tab. Let me know if I should open an issue for this.

[grnassar]

The main thing I do in a browser is 'browse websites'. It is not, and never will or should be 'think about or interact with containers'. So containers should be layered on top of normal browsing,

Up to here, I agreed with you entirely. :)

and not something you have to do prior to browsing (in your case, that would be to open up a new window with the right container).

That's where you lose me. How is it relevant if you're thinking about/interacting with containers prior to browsing, rather than (as in your examples) during?

I want to "browse websites." I don't want to "think about or interact with containers." And yet -- my browser can't read my mind, and I want websites contained, so obviously I must interact with containers to some degree. So, my goal is to minimize thinking about them as much as possible. Having a default container per window allows me to make a simple decision and interact with a container decision once per role -- and for the rest of my web browsing, my natural desire to organize my tabs based on what tasks I'm doing/roles I'm fulfilling will also, conveniently and with no interaction from me, open all links in their correct container. So when I'm doing work stuff in the window that has all my work tabs, if I need a new tab I open it and - voila - it's in the work container. My work FB will see that I'm already logged in to my work LinkedIn, and email links will open in my work email account. If I then want to Hangouts my niece, I don't want that tab in with my work stuff! I switch to my personal window - which I set to the personal container at the beginning of the day - and open a tab, already logged into my personal Google account from earlier in the day of course, and open Hangouts without a second thought. Everything just works.

Sticky Containers (haven't tried Sticky Window Containers yet, but I'm looking forward to it) tries to do something similar, but it's too clever by half: the complexity of the implementation makes for buggy, inconsistent results when it comes to opening non-"default" tabs. Assigning a default container for a window, by contrast, is a simple, elegant solution to the same problem. If anything, the close tying that you want of containers and "logging into accounts," as you describe, is even more complex. So, now the browser has to sniff your input to FB to determine if the account you are logging into is container A or container B? OK -- and every other site you log into as well, of course; so if you have FB over here open in container A and two tabs down you have LinkedIn open in container B, and you are using XYZ Productivity Software and open the online help... which container will that link open in? Is every site that doesn't have a login assumed to be a no-container site until you say otherwise? Because that is an awful lot more interaction with containers than I want to have -- especially when I'm in the middle of ostensibly productive work!

However the decisions are "selected," the logistics to build out something like that are orders of magnitude more complicated than a simple "assign X container to Y window's new tabs" logic. 80% of the use case solution, 5% of the work.

[grahamperrin]

From opening post #1490 (comment):

one problem

@eoghanmurray your first problem might be solved with the complementary Always In Container extension.

tiansh/always-in-container#6