-
Notifications
You must be signed in to change notification settings - Fork 323
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
Option to open new Tabs in the same Container #462
Comments
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) |
@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. |
@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. |
Typing in the location bar and hitting alt+enter should definitely open in the same container, regardless of this particular request's outcome. |
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. |
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: |
@groovecoder can you not combine: 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. |
Hmm ... the
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. |
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? |
Note: check out https://github.com/kesselborn/taborama which is implementing this. |
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. |
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. |
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. |
@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. |
I don't mean to unmotivate, just wanted to provide my perspective to the discussion I've been following. |
Spin-off: https://discourse.mozilla.org/t/-/15331/4?u=grahamperrin |
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).
|
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. |
This commit adds functionality that will try to open new tabs in the same container as the previously active tab in that window, if the new tab doesn't already have a container, and the previously active tab did. Some undocumented / implicity functionality in the webextension API is used: * `onCreated` is called for a new tab before `onActivated` for that tab is called * `onUpdated` will be called for all new tabs, also `about:newtab` and the like (sets the favicon) * The first `onUpdated` for a new tab, that is not an `about:`-tab, will set the URL It is a little bit wonky, as the original new tab is created and displayed (although not loaded) before it can be closed a new tab can be created. However, it is the best workaround I can find to add this functionality until Bugzilla 1406371 is solved. This would fix mozilla#462, mozilla#448 and mozilla#406 (I think) Also relates to mozilla#943 and mozilla#544
Edit: Found this comment to customize the container-specific shortcuts. Withdrawing my comment as irrelevant to the original issue. |
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". |
@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. |
I wasn't able to glean this, though I admit I haven't read every comment: is there an existing Firefox issue for overriding |
I was able to produce the wanted behavior using a combination of Karabiner Elements and @jonathanKingston's extension
|
Thanks, that helped me a lot. |
I am not able to set CTRL E as the shortcut. Is there any trick to do this? |
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. |
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. |
I came across Firefox Autoconfig when I was researching about overriding Firefox default shortcuts. Using Autoconfigs I was able to override 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: Tip: Use Browser Tool Box (Cmd+Option+Shift+I) for debugging the scripts References: |
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. |
Hi all, you can use Tree Style Tab extension for this with setting on picture |
finally something that works |
Tree Style Tabs uses a bit of hack:
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. |
@Roy-Orbison Thank you for expanding that acronym. I wasn't aware of what it stood for. /cc @altynbek132 |
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. |
@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. |
Fair point. |
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. |
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.
The text was updated successfully, but these errors were encountered: