"Open always in no container" setting

[WhyNotHugo]

There are sites that I never want in a specific container but rather "no container".

While pages in containers have a "Open always in this container", there's no opposite option: "always open this outside any container". (I'm not sure if this is called outside a container, or rather the "default" container, but let me know if this needs further clarification).

[jonathanKingston]

Would it be easier if we treated "default" as a container. So right clicking "Always open in this container" would behave in the same manner? Users would be redirected from work:evil.com to default:evil.com

[ArchangeGabriel]

@jonathanKingston Yes, the “default” should be a container I think. Because it technically is anyway, right?

[jonathanKingston]

@ArchangeGabriel technically isn't a container, so it's explicitly not permitted there. However its probably a sane use case to change the assignment to allow "Always use in default tab" or whatever branding we use for "default".

[jonathanKingston]

@groovecoder this probably is something we can/should add, what do you think?

[WhyNotHugo]

I don't mind if "default" is a container or not (I don't think it makes a real difference). That's really more of an implementation detail and the same use-case can be covered with what you're proposing anyway.

The use case is basically:

• I've a youtube page on the youtube container.
• I click a link to some external site (eg: github). My uncontained session has me logged into github, but the youtube container doesn't.
• A tab opens with the youtube container active, so I'm on github without my session.

The last step should really be "github opens in a containerless tab".

TBH, there's an alternative implementation which would also help (and quite related), which is "only open X domain in this container" (eg: exclude any unlisted domains), but that sound a lot more complex and almost out-of-scope, at least for now.

[jonathanKingston]

Yeah I would like to change the default link clicks of assigned pages somehow but I don't think it is possible in this experiment.

[jonathanKingston]

The only implication in adding this would be we are adding new ability to manage container assignment. To add this we would need a default row in the containers panel like:

Such that the user could do this:

I guess we could put it at the end of the list as we don't want to make it a focus for users.

[smichel17]

I don't mind if "default" is a container or not (I don't think it makes a real difference).

I could not disagree more strongly. "Is 'default' a container?" is a variant of the single most important question about containers: "What is a container?" The answer is going to inform every single aspect of container UX and functionality.

Right now, I don't think there is a clear answer; instead, we define containers by their functionality. A container is a way to protect yourself from tracking across the web, to browse the same site with multiple accounts, and to organize your tabs. The problem is, this kind of definition doesn't provide much intuition about how you'd expect containers to act, which leads to ambiguous questions like this very issue.

In many ways, this whole test pilot experiment is about figuring out what a container should be.

I have some thoughts, but they're still fragmented and also are larger scope than just this issue. @jonathanKingston is there an irc channel for this experiment particularly, or just #testpilot?

[TanviHacks]

Until we work this out, I propose we remove the checkbox and the "Always open in Default" text entirely when a user is in a default container.

[grahamperrin]

Maybe off-topic … I imagine that in a majority of cases, it will be sane to enforce non-containment of about: … URLs.

[martinthomson]

Remember that most users that install this extension will have a bunch of stuff assigned to "No container" and moving things is pretty annoying. Treating "No container" as first class in as much of the UX as possible will ensure that you have a reasonable transition story. I can see why you might block things like deleting the "No container", or other such things, but that list should be very short and have an easily understandable story for each place where this is special.

[antimatter84]

I read through this issue and I'm not sure I get the goal of this issue. I both tested the MAC and Facebook Container addons and noted that the Facebook Container (being a specialised MAC just for FB) opens links to pages outside of Facebook in the default container. This is not happening in MAC where I configured my Facebook container to always open Facebook in that container.

In general, when browsing to site A in the A-container and then clicking a link to site B, it is opens in that A-container.

So, in my opinion (it may have been discussed here already) any domains not currently assigned to a container should open in a tab of the default container.

[stoically]

@antimatter84 Although that might be your desired behavior, other use-cases do exist.

[Dom-R]

I would like to show my interest in this feature. I don't see the purpose of not allowing specific websites to be an all purpose use. In my example I don't want/need to have github logged in in two or more different containers.

[mozjag]

I would like this as well. I use containers for sites like Reddit and banks, but have most other stuff, including all the Google sites, in the default "container" (not really a container, but that's now my mental model). I'd therefore like to have YouTube automatically open in default and not the Reddit container.

Yes, I could migrate all my Google stuff to a new Google container and work around it that way, but that feels like I'm fighting the container system instead of it working for me.

I suppose another option would be some generalized version of the Facebook Container and Google Container addons so I can automatically have anything not white-listed be opened in default.

[blackjackshellac]

Another vote for this feature. Would it be easier to allow for configuration of the Default container to be a different container so that when a new tab is opened it defaults the configured My Default. Then you'd be able to click the Always open in My Default checkbox.

[jessebrennan]

I just wanted to point out that #1194, which is requesting to fix this bug has 30 :+1: , so there is clearly a lot of user value in setting sites to always open in the default container.

[d4f5409d]

Hello! I'm looking for this feature too. It would help me alot since I use specific themes at specific pages, synced with cookies. It's kinda odd to see eye-burning light theme on a site, when I did set it in the default container already to black.

[thevoiceless]

Hopefully we get this as an official option, but in the meantime the Containerise addon allows assigning domains to "no container"

[endolith]

Any progress since this was posted five years ago? :/

[jokeyrhyme]

There's probably less reason to use Container Tabs at all now that Total Cookie Protection is rolled out: https://blog.mozilla.org/en/mozilla/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/

And especially if you have Enhanced Tracking Protection set to Strict

[dannycolin]

And especially if you have Enhanced Tracking Protection set to Strict

Total cookie protection set to Strict can breaks websites. Setting it on standard and isolating the website in a container might be a more viable solution for a lot of users.

[jerryskye]

There's probably less reason to use Container Tabs at all now that Total Cookie Protection is rolled out

My primary use case for containers is having separate sets of cookies for the same website, does Total Cookie Protection have an impact on that?

[dannycolin]

My primary use case for containers is having separate sets of cookies for the same website, does Total Cookie Protection have an impact on that?

TCP only isolates domains from each others. If you want to isolate the same domain on which you have for example two accounts, that's a good use case for Containers.

[influential-eliot]

Just here to upvote this and suggest functionality that expands upon it, too.

The default container should be optional at the base level, that also means that it should be optional that zero sites can open in the default container / no container.

I would say this would be a good set of base options that would not affect the existing setup:

1. Disable default (no) container and ask for every non-configured site
2. Disable default (no) container and open non-configured sites in specific container
3. Disable default (no) container and open non-configured sites in private browsing
4. Enable default container and open non-configured sites in default (existing setup)
5. Enable default container and ask for every non-configured site

I think I'm missing an option, there, but I think that (at some stage) private browsing needs to be a part of this conversation.

( plus let us edit the tab site lists and pre-configure bookmarks to open in specific tabs without prompting the 'are you sure' query :wink:)