-
Notifications
You must be signed in to change notification settings - Fork 335
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
Opening a new tab from a container window opens a normal tab and not a container tab #245
Comments
This is as intended, but I have a feeling people will treat this as a bug, so let's keep it open. |
@johngruen What do you think about this? This is like a Container Window feature. |
User here. I expected that when I opened a new tab, it would be the same container type as whatever my current tab was. That is, even if you omit @SoftVision-EmilPasca's steps 3 and 4. edit 2017-03-03: The reason is, that's the context in which I'm browsing. I don't expect to change contexts without actively deciding to. |
If you want to inherit the current tab's container you need to middle/ctrl + click the new tab button (Firefox 53+ Bug 1325014), this also creates the new tab next to the current tab. A normal click on the new tab button creates an unrelated tab at the end of the tabstrip and so should not inherit the current tab's container. |
I wrote a response to this, but then realized that we're trying to solve the wrong problem. The real problem here is that we force the user to pick a context before they enter the URL.I seldom open a new tab thinking "I want to do something in [some container]!" I open a new tab thinking "I want to visit [some site]!" THEN, once I've opened the tab and typed the URL, I think about what container this belongs in. Sometimes, I open a new tab, start to type something, then change my mind about what I want to open. Under the current workflow, I need to close this tab, open a new tab in the new context, and then type the new URL. That just doesn't work very well. Here's a mockup I made in #311 that is also relevant here. I'd love to have this instead of the current awkward pop-up to choose a container for my new tab: My original response:
|
I tested nkestrel's reply - a middle click on the new tab button does, indeed, open a new tab in the same container. I'll have to double check that no TMP settings interfere with this, but so far, it looks like this is a good enough solution for me, as I make heavy use of left-, middle- and right-clicking in Firefox. |
What about a keyboard shortcut to open a new tab in the current context? Also middle clicking on the button does not open it in the same context for me. |
@jurf I think that would be ideal if the developers don't want a different shortcut for every container (alt+1, alt+2, etc.) |
@imyxh is already taken; it opens the most recently closed tab. |
@smichel17 Oh. Right. I use that all the time, come to think of it. |
Alt-T = Tools menu (Firefox on KDE Plasma 4 on FreeBSD) Points of reference that may be useful include:
– and so on; generally, I should refrain from predefined shortcuts. Allow the user to set a preference, if he or she finds the need for a shortcut. |
Not sure if this issue is progressing at all, but:
For my use, I do want this. I want every URL in a window to be in the same container. If I hit Ctrl-T from an existing container tab, I want that new tab to be in the same container. Not exactly the same things, but I think the latter makes the former easier to maintain. Middle-click on the new tab button works, but I never use the mouse in opening new tabs - my flow is Ctrl-T, start typing URL or partial search terms. Basically, I don't want to make container decisions on every new tab. I'd like to just roll with the container I was last using in this window. Opening links in a new tab from a container tab works this way; I wish opening a new blank tab did too. |
@lmorchard I don't think our views are in conflict here. You just want the default selection to be the same as your current container. (For the record, I would prefer that, too, or in private tabs like #429.) |
Could a setting be added that makes it so new tabs inherit the container they where "opened from"? By default it would be disabled, so typing I feel like making this a setting is a reasonable way to provide users the power to choose their interaction style without interrupting the new-tab process. Thoughts? |
I would support the idea of it being optional instead of a new hotkey or its forced to anything. |
Duplicate of #462 which has more up-votes. Please transfer any up-votes there (if you haven't already). |
Tree Style Tab by Piro has a function that lets you automate this for opening a new tab. It works for me with:
My version of TST is 3.5.34 - I run a legacy version due to not liking a an update to how groups for tabs are created with a recent update. Edit: Had to make lots of edits and delete previous revisions; the image I uploaded refused to be rid of the cut-away section (showing my browser and other private information) even if I had deleted them in my image editor; must be some quirk I have not fully understood yet. |
[Affected versions]:
[Affected Platforms]:
[Prerequisites]:
[Steps to reproduce]:
[Expected result]:
[Actual result]:
[Notes]:
The text was updated successfully, but these errors were encountered: