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 #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.

[awmartin]

As for container-specific shortcuts, Ctrl+Shift+<number> does not work for me on macOS, but Cmd+Shift+<number> does, which unfortunately interferes with the system-wide standard screenshot shortcuts: Cmd+Shift+3, Cmd+Shift+4, and Cmd+Shift+5. There's no way to customize these in Firefox 94, as far as I can tell.

I'd much rather disable them in lieu of this add-on, which adds Alt+Shift+ on macOS, the only thing that works for me.

Edit: Found this comment to customize the container-specific shortcuts. Withdrawing my comment as irrelevant to the original issue.

[nk9]

If there were an appropriately-named menu item, say "File > New Container Tab > In Current Container", then users could bind this menu item to whatever keyboard shortcut they wanted. On macOS this ability is built in.

As it stands, the contextual menu in the tab bar has "New Tab," which opens a new tab in the current container. But the identically-named "File > New Tab" menu item uses no container. I personally find this a bit unexpected. If the behavior of the two items is going to be different, IMO it would be clearer if the context menu said "New Tab in Current Container".

[Roy-Orbison]

@nk9 That functionality is already available via an add-on, and Firefox has the ability to edit extension key bindings.

This issue is and always has been about making it possible (and preferably the default) for Ctrl + T to keep the current context. This is because loss of context is unexpected, that key combination cannot be bound to anything else by users, and we should not have to mess with key bindings for basic functionality, regardless.

[DanKaplanSES]

I wasn't able to glean this, though I admit I haven't read every comment: is there an existing Firefox issue for overriding ctrl+T? Can someone reply with a link to it, and then maybe @MichelZ can add it to their original post for visibility. I guess I'm assuming they have a voting system, too.

[Roy-Orbison]

Mozilla bug #1320332

[mrassili]

I was able to produce the wanted behavior using a combination of Karabiner Elements and @jonathanKingston's extension

• First you need to install the extension

• Then change its default shortcut from ALT+C to any shortcut e.g. Shift+Command+0 (should not be a built-in Firefox shortcut)

  • To change it go to about:addons click on the ⚙️ menu and click on Manage Extension Shortcuts option

• and then go to this page I created to add a complex modifier to Karabiner Elements that basically just maps Command+T to Shift+Command+0 on Firefox only!

  • Hit the Install button and follow the instructions on Karabiner Elements to enable the new rule

  Now you should be able to hit ⌘T to open a new tab in the same container 🎉

[vlad0337187]

@nk9 That functionality is already available via an add-on, and Firefox has the ability to edit extension key bindings.

This issue is and always has been about making it possible (and preferably the default) for Ctrl + T to keep the current context. This is because loss of context is unexpected, that key combination cannot be bound to anything else by users, and we should not have to mess with key bindings for basic functionality, regardless.

Thanks, that helped me a lot.
Assigned new tab in same container to CTRL-E.

[VasuInukollu]

Assigned new tab in same container to CTRL-E.

I am not able to set CTRL E as the shortcut. Is there any trick to do this?
When I try, I get this message "Can't override a Firefox shortcut".

[archon810]

@nk9 That functionality is already available via an add-on, and Firefox has the ability to edit extension key bindings.

Thank you for the link, it's working as expected. I customized the shortcut to Ctrl+Alt+T.

[daraul]

I often open URLs from some other application, that indeed are meant to be opened in some container. I am normally already using some tab in that container when this happens. Therefore, I would prefer a configuration setting that tells Firefox to open any new tab in the container of the current tab.

---

If anyone is interested: I worked around the lack of this feature with stick window containers, but the extension caused some annoyances that lead me to remove it.

[rykel]

I am not a developer, but I would like follow this issue because I would like to open multiple tabs in the same container. Thanks for all the hard work, devs.

[arunvelsriram]

I came across Firefox Autoconfig when I was researching about overriding Firefox default shortcuts.

Using Autoconfigs I was able to override Cmd+T to open new tabs in a specific container (container 0 in my case). The scripts are available here:

autoconfig.js
autoconfig.cfg

These can be modified to open tabs based on the current tab's container. Even these can be modified to override the behavior of the New Tab (+) button as well I guess.

In case of OS X place or symlink the configs in below location:
/Applications/Firefox.app/Contents/Resources/autoconfig.cfg
/Applications/Firefox.app/Contents/Resources/defaults/pref/autoconfig.js

Tip: Use Browser Tool Box (Cmd+Option+Shift+I) for debugging the scripts

References:
https://superuser.com/a/1747680/244485 https://superuser.com/a/1785959/244485 ( these answers were great)
https://github.com/Theemim/GeckoAutoconfigIntro#mike-kaply-articles
https://www.reddit.com/r/firefox/comments/p89mvd/how_can_i_make_the_browser_toolbox_visable_in_the/

[Roy-Orbison]

Thanks @arunvelsriram for that. I'm almost tempted to give it a try. At least it adds weight to this issue because users should not have to go through that much rigmarole to have a sensible shortcut.

[altynbek132]

Hi all, you can use Tree Style Tab extension for this with setting on picture

[VasuInukollu]

Hi all, you can use TST for this with setting on picture

finally something that works

[Roy-Orbison]

Tree Style Tabs uses a bit of hack:

1. It observes all tabs being opened
2. Assesses whether it thinks they are "new tabs"
3. When the last active container was not the default/"no container", it opens another tab with the container set
4. It then closes the original tab you opened

It's not a bad hack but it doesn't solve the core issue, and it's not quite the same as opening a new tab with the container already set (as Retainer does). It's relatively heavy if all you use it for is to keep the current context.

Reference.

[DanKaplanSES]

Tree Style Tabs uses a bit of hack:

@Roy-Orbison Thank you for expanding that acronym. I wasn't aware of what it stood for.

/cc @altynbek132

[jwbth]

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

Ctrl+T doesn't bother me as much as Alt+Enter. My typical use case is that I change some part of the URL and want it to open in the same container, but in a new tab. And there seems to be no way I can do it. If the devs, for some reason, prefer to keep the old behavior for Alt+Enter, then please provide a modifier like Ctrl, Shift, middle click or whatever. Are they all occupied or what? Damn, I can't even make a middle click on the arrow button, like I do with the "+" (New tab) button, which makes the address bar totally misleading:

The new tab won't be opened in the "Personal" tab, despite what the address bar says, no matter if you make a middle click or hold a modifier. With Alt, it just opens the URL in the same tab.

[AdamWill]

Another vote for something like this. What I actually want is the exact behaviour of the Sticky Window Containers extension, but without having to install an extension from a random author which has not been updated for three years (and is probably a prime target for a takeover attack) to get it. I want all tabs in a given window to open in the same container by default, including if I have that window active then click a link from another application, or middle-click a link from another tab in that window. Not sure if that counts under this issue, or there's another request for that. Thanks.

[Roy-Orbison]

@AdamWill I fully agree with your desire for better containment, but a lack of plugin updates can also indicate stability. If it doesn't have open issues, and it's working for you, it probably doesn't need to be updated. Simple plugins don't provide much of an attack surface. Mine's literally listen for a shortcut event (provided by Firefox, not it monitoring keystrokes), then open a tab.

[AdamWill]

Fair point.

[mattolenik]

Another vote for this. It is SO easy to accidentally open something in the wrong container. If I'm "in a container" I would expect new tabs to be in the same container. The mental overhead of having to explicitly put care into opening new tabs for each container makes the whole thing kind of useless, unfortunately. This seems like a no-brainer from a user interaction point of view. It's the most top voted issue for a reason.