Option to open new Tabs in the same Container

[MichelZ]

I often CTRL+T to open a new Tab. Currently, these are opened in the Default Container. It would be nice to at least have a configurable option to open new Tabs in the Context of the Tab I'm currently working on.

I am a system admin, and I do need to use different personas, often even for the same sites. Also, when I am working with one persona, I often need multiple tabs for the same persona, so this would help me not needing to change the persona on every new tab.

As mentioned above, saving the URL to always open in the same Container does not work for me, as the same site needs to be used with multiple personas.

[Nainterceptor]

I've suggested in test pilot feedback to be able to open with Ctrl/Cmd + T a new tab without container, then add Ctrl/Cmd + T + n (where n is a number) to open a new tab in the numbered container (by order in the list).

Another option may be to show another "new tab controls" option to see possible containers, then bind a key to each container, so we can open with Ctrl/Cmd + T then the key (better for fingers & accessibility, because some combinations like Ctrl/Cmd + T + n are not easy with only one hand)

[anewuser]

@Nainterceptor Your suggestions are as valid as anybody else's, but please don't take the focus away from @MichelZ's idea, which is simply to make new tabs open in the same container as the current tab with the 2-key shortcut we've been used to for many years.

[Nainterceptor]

@anewuser Mhhh, nevermind, I've understood "vote for me" label as an open debate, I've seen a feature close to the one that I want, and I try to add my idea to this one. So, I guess that is not open to comments.

[WhyNotHugo]

Typing in the location bar and hitting alt+enter should definitely open in the same container, regardless of this particular request's outcome.

[TitanNano]

Also just clicking the "new tab" button should open the tab in the same container. Maybe the color of the + can be changed to the current container color.

[groovecoder]

I'm pretty sure this needs code in m-c. I can't seem to get the right combination of tab event handlers to make this work in a browser extension. Here's where I'm trying:

https://github.com/groovecoder/new-tab-same-container

[jonathanKingston]

@groovecoder can you not combine: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webNavigation/onCreatedNavigationTarget

with a blocking onBeforeRequest?

I will try and make a sample tomorrow, looks like 54 supports this and it should be better for assignment also. This is neater for this solution as I think you will be able to check the cookieStoreId for the frame the request came from.

[groovecoder]

Hmm ... the onCreatedNavigationTarget specifically DOES NOT fire when the user creates a new tab.

The event is not sent if a tab or window is created without a navigation target (for example, if the user opens a new tab by pressing Ctrl+T).

So, it could work, but the tab won't switch into the container until the user makes a navigation request, which isn't what this particular issue is asking for.

[jonathanKingston]

I wonder if on tab created that is default should just open in the current container if there is one would be good enough here. And perhaps the navigation target could be an exemption to this rule?

[groovecoder]

Note: check out https://github.com/kesselborn/taborama which is implementing this.

[sametmax]

I'm +100 on this, although I understand the current default behaviour. Just an alternative keyboard shortcut would do. Like @hobarrera I think ctrl + enter should open in the current currext.

BUT.

For the people currently looking for a workaround, you must know that CTRL + Click or middle click on the "new tab" (the plus sign) button will open a tab in the current context. It helps a lot already.

[gee-forr]

CTRL/CMD+Click or Middle click won't work for users like me that have hidden the tab bar.

I've hidden the tab bar because I like my tabs on the side, ala Tab Center, so I don't actually have a tab button to click anywhere.

I'm willing to rewrite years of muscle memory for a shortcut for a context aware new container tab, but first prize would definitely be for Firefox to assume that the current container I'm in is the current container I wish to stay in.

My main reason for this is; consider Google style properties where you have a single account across many many services. I'm viewing something on youtube in my personal container, and then decide to read my personal email, so I open up gmail, except it opens up in the default container which is isolated from my personal container, and thus requires another auth.

This is extremely confusing, and moreover, surprising.

[crenwick]

After discovering and installing this add-on, I up'ed and followed this issue. Now, after using it for a few weeks, I feel like I have a better understanding of this feature, and the enhancements that would make it perfect for my browsing behaviors.

I now disagree with my original assumption and now think that new tabs and windows should always open in the default container. To go one step further, I think that the option to open new tabs in the same container would muddle this feature and would make it more difficult for new users to understand containerization (and that its strictly not related to about:profiles or about:accounts).

Now what I desire is a seemless way to switch my current tab to another container. This could be something like https://github.com/mozilla/multi-account-containers/issues/849, (where I'm prompted for a choice if I go to a url that's assigned to multiple containers) or it could just be a keyboard shortcut that reloads my current tab with a different container.

Anyways, I'm going to unfollow this issue but thought I would voice my thoughts before I leave.

Edit: I just saw https://github.com/mozilla/multi-account-containers/wiki/Moving-between-containers which eliminates the reloads idea but I believe a prompt before loading the URL could still be viable.

[anewuser]

@crenwick It's great that it works fine for you, but a lot of other people in this thread do need/want this feature, so I don't see the point of your comment (you hadn't commented here before) other than to unmotivate us.

[crenwick]

I don't mean to unmotivate, just wanted to provide my perspective to the discussion I've been following.

[grahamperrin]

… taborama … implementing this.

Spin-off: https://discourse.mozilla.org/t/-/15331/4?u=grahamperrin

[tkolo]

For me it'd be best if there was an option to ditch the "default" container altogether. It just doesn't fit. I have a container for pretty much every use case I need, which means if I open tabs in "default" container it's clearly a sign that I forgot to pick a container (or firefox forgot to assign one). This solves the original problem in here in a pretty straight forward way: If default container is no more, firefox has to ask me what container to assign every time I open new tab. The method to do that is pretty much out of scope, but it could be:

• multiple shortcuts (Ctrl + T, Y, U, ..)
• context menu
• custom tab that makes me assign it's container before it "transforms" into new tab
• ... ability to choose another default container from the set of already defined

[aleksijohansson]

CMD+T opening a new tab in the default container instead in the container I'm currently in keeps me from using Firefox and I so really much would like to. I 100% agree and second the original issue description.

[NenoLoje]

Anyone knows what the current status here is, especially for keeping [Alt]+[Enter] in the same user identity?

Thanks, --Neno

[chicagobuss]

Been a long time since this was requested... alt+enter and ctrl-t should both use the current container... or even better, let us set a 'default container' for those operations !!

[MichaelTunnell]

This feature request already seems to be solved by jkt? -> https://addons.mozilla.org/en-US/firefox/addon/new-container-tab/

I use this extension all the time. Essentially it does what is being asked on this issue but instead of Ctrl+T it uses Alt+C which I think is a reasonable solution. I like the idea of Ctrl+T always being the non-container option because I often want both so it taking over Ctrl+T would be a negative in my opinion.

[anewuser]

@MichaelTunnell Please read the previous comments. Many of us don't want to use another shortcut.

so it taking over Ctrl+T would be a negative in my opinion.

That's why things can be optional.

[jurf]

How do you people actually use this extension without this?

[kaleissin]

I think the safe (paranoid) option is that "no container/default container" means the tab is opened in it's own temporary container. it should then be fine to move the tab to an existing container after the fact. This is the paranoia option though, and cannot be the default. I usually use private windows anyway even if it means I have to log in often. (I wish "open in firefox" meant opening in a private tab even.)

[fxedel]

Maybe another approach would be extending the convenience of the existing Ctrl+. shortcut by automatically focusing the current tab's tab group? Then, only Ctrl+. and Enter would be enough to open a new tab in the same container.

[kemayo]

So, point for discussion: I've just written an add-on which does this.

https://addons.mozilla.org/en-US/firefox/addon/sticky-containers/

This is the first Firefox add-on I've written, and the first thing using WebExtensions, so I make no promises that I'm not mangling something, or missing some important cases. But.

I felt the earlier-mentioned new-container-tab extension was insufficient for what I wanted because there wasn't a way to have it bind to the regular ctrl-T shortcut, and it didn't affect links coming in from outside Firefox. I want to click a link in my work IRC client, and have it open in the Work-profile Firefox window I have on that desktop, basically.

[TitanNano]

@kemayo Your add-on doesn't work for me, I'm running 62.0b2.

Unchecked lastError value: Error: Missing host permission for the tab background.bundle.js:23
tab onActivated Object { tabId: 16, windowId: 3 } background.js:57:3
cookieStoreId changed from firefox-default -> firefox-container-1 background.js:42:7
tab onActivated Object { tabId: 28, windowId: 3 } background.js:57:3
Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:155

[kemayo]

@TitanNano: Not sure what's happening there. Both of those errors reference files which aren't in my extension, so I think they might be red herrings. It's plausible that I just need more permissions, and for some reason I'm not seeing that being a problem locally. (Either because of some extension development quirk, or because I'm using release-firefox rather than 62.) As such... I've put up a new version which asks for <all_urls>, as a magic incantation against "missing host permission".

[anewuser]

There are many people subscribed to this issue only to get updates on an official "Option to open new Tabs in the same Container".

Please stop posting things about extensions here, and report their bugs to the appropriate repositories or support forums.

[MichaelTunnell]

There are many people subscribed to this issue only to get updates on an official "Option to open new Tabs in the same Container".

There are also people who are subscribed for a solution of any kind, official addon or not. So I hope people continue to post extensions they've made for any of the issues in this repo.

However, I do agree that bug reports should just be on the issues portion of the extension repo not here.

[ivanhercaz]

I am very interested in this issue. Containers are an awesome feature, but they need to be refined. One of the things to improve is what @MichelZ and many other people have suggested in this issue.

But the issue was opened in 2017, and now, one year and more later, after read this issue, I didn't read something about this suggested enhancement. Anyone involved with the development of multi-account-containers know if there has been any progress or if this is bogged down?

In addition, there are another related issues in the same situation, as the #319.

[gee-forr]

I recommend you install the Conex extension https://addons.mozilla.org/en-US/firefox/addon/conex/. It works around this issue, and you get a kind of tab-groups experience too if you want.

[MichaelTunnell]

@gee-forr Conex is a nice extension that solves many issues and has a nice throwback somewhat to TabGroups. However, it is not at all close to what this thread is requesting regardless of the 2 ways that are being requested.

I like in Conex but it is more of a consolidator of features that in some cases I'd rather have separated.

1. always open new tab in current container
   • nice but also available with sticky containers
2. Ctrl+T to open new tab in same container
   • I prefer a separate keybind approach so Ctrl+T is no-container and Alt+C is new tab in current container. (I would prefer it switched but overall separate is ideal for productivity to me)
3. Switch current tab to a new container
   • this is already available now in the main extensions of Containers.
4. quick access to open new tabs of a specific container
   • Easy Container Shortcuts does this way better with specific shortcuts per container.
5. Opening bookmarks into containers
   • this is the goal of this thread but this bookmark search method is terrible for people who have over 1,000 bookmarks as I do. Navigating through the sidebar or the bookmarks bar is MUCH better. This extension offers support via Bookmarks Bar and Sidebar is in development.
6. A popup menu that can be navigated by the keyboard.
   • I would prefer it in the sidebar but sea containers can't be navigated by the keyboard so Conex is better here.

Ultimately, Conex is good in an overall feature set but I think these separate extensions together make a better experience vs Conex. Hopefully, they will see what makes those extensions good and implement them.

[jbcpollak]

I'd really like this feature. Coming from Chrome the current behavior is exasperating and counter-intuitive. I agree that with containers enabled there should be no "default" container (or the user should be able to set a default container) - new tabs should inherit whatever container the tab that had the focus when it was created was using.

[swirle13]

Seconding the opinion of no "default" container, especially as that is the default behavior of opening a new tab with Ctrl T or the + tab. I'd rather open something in my container of choice, then choose "oh shoot, that shouldn't be in work container, but personal" and then move over to the proper container in the url bar, like the current and intentional behavior is.

[djee-ms]

Aside from the +1 on the Ctrl+T feature request, which is really the best solution IMHO, I'd like to offer a possibly easier alternative (or addition) which is to have multiple "+" buttons, one per container color. This would already be an improvement, although really the Ctrl+T is the best one for me from a UX point of view (no context switching to mouse while hands are on the keyboard already).

[nipunarora]

+1

• I was trying to find this functionality and was dissapointed to see it's not there by default. What alternatives do we have?

[warent]

Bummer, I thought for sure this is how containers worked. Disappointed to see that it's not. This has been open for years now and is a popular feature. Any plans on getting it added soon?

[leonardoarroyo]

Posting here to help the visibility of the issue as a popular feature request. +1

[64kramsystem]

Hopefully, with enough attention, at least an addon will be developed 🥺 Sticky containers would do the job, but it's broken.

[bettyvschmartz]

Using ctrl + period + the container # does the trick but this is long overdue. I agree that default behaviour of ctrl+t should respect at least the current container, and at best be configurable to pick a container default. It's especially strange UX when you have 'Select a container for each new tab' ticked and ctrl+t even ignores that.

-- BVS

[altsalt]

Using ctrl + period + the container # does the trick

Containers are not numbered afaik. Just tried it in FF83 and do not see any pattern when selecting different numbers.

[bettyvschmartz]

Using ctrl + period + the container # does the trick

Containers are not numbered afaik. Just tried it in FF83 and do not see any pattern when selecting different numbers.

Containers are numbered. See release notes for 7.0.0 here and commit 8654aef which seemed to fix a bug with it not working.

Check the preferences for Multi-Account Containers and you can even set what container is what number.

-- BVS

[WhyNotHugo]

Nice. ctrl+., 1 works nicely for me.

It would be great if the popup menu that appears showed these numbers to makes this more obvious (especially for all those users who don't follow this thread).

[Roy-Orbison]

There's a bug ticket in core that predates this one https://bugzilla.mozilla.org/show_bug.cgi?id=1245262

[moontails]

happy to work on this! :)

[moontails]

@bettyvschmartz

i somehow lean towards this being a window default rather than at the tab level.

use the default order as priority so when the application is started, the first window is the first one from the default . let users configure shortcuts or we can go with ctrl + n + 1.

i feel like my reasoning is a key thing about the container experience. if user wants to have multiple logins in a session, rather than using incognito + multiple browsers, there is no other option, unlike chrome. extending this hypthesis, its evident that having these two containers sit side by side can lead to confusing and unintended consequences, in between context switching, u send a personal reply in your work email to name a mixup usecase.

making users change to using a different shortcut seems like a bad cx for the feature. ctrl + t is the simplest way other than clicking the button.

if y'all think this seems reasonable, i am happy to contribute my dev time for this feature.

[Roy-Orbison]

To be a window default, containers would have to be per window, which I don't think anyone is asking for. This doesn't really resolve the gripe: you're in a tab in container X, you open new tab, it's in container Y (or none), either way not the "current" container.

[moontails]

@Roy-Orbison thats exactly what i am suggesting to support this issue. There are also other explicit requests like #319 if you wanna go validate if there is a real ask for this.

i get how you are saying about containers being tab specific, but after setting up my containers (and authenticating to various commonly used sites), it becomes increasingly frustrating to use firefox as default browser. see example below

ex - i have all my X related container tabs grouped under 1 window and other Y related spaces in a different window, now when i get pinged on an application like slack and i click on the link, it opens in the last active window but in a normal tab as the link from the external app has no container context. this breaks if the url in question needs auth context, as the auth context is set in my other X,Y containers.

the workaround is to manually open a relevant container tab and copy paste the url. this is tedious and isnt optimal CX.

[Roy-Orbison]

@moontails It sounds your issues would mostly be resolved by #706.