Opening a new tab from a container window opens a normal tab and not a container tab

[SoftVision-EmilPasca]

[Affected versions]:

• Firefox 51.0.1 and up
• Containers Experiment 0.9.3

[Affected Platforms]:

• All Windows
• All Mac
• All Linux

[Prerequisites]:

• Have Containers Experiment(v0.9.3) installed on a Firefox new profile.

[Steps to reproduce]:

1. Open the browser with the profile from prerequisite.
2. Open any containers tab and navigate to any website.
3. Click on the "Containers" button in the toolbar.
4. Click the arrow next to the previously used container and choose to "Move tabs to a new window".
5. Press "CTRL+T" and observe the newly opened tab.

[Expected result]:

• A new tab is opened and is part of the same container.

[Actual result]:

• A normal new tab is opened.

[Notes]:

• After step 5 you no longer have the context-menu option to open tabs in that container.
  

[johngruen]

This is as intended, but I have a feeling people will treat this as a bug, so let's keep it open.

[TanviHacks]

@johngruen What do you think about this? This is like a Container Window feature.

[smichel17]

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.

[nkestrel]

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.

[smichel17]

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:

That's awesome functionality that I didn't know about. Is there a keyboard shortcut that does the same thing? I open most of my new tabs with <Ctrl-t>.

I'd encourage the devs to add a notification of some sort the first time a user opens a new tab when they are currently in a container, letting them know how to open a new tab with the same context. Then track how often people choose to keep the same container vs start a new one.

[JohnLGalt]

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.

[jurf]

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.

[imyxh]

@jurf I think that would be ideal if the developers don't want a different shortcut for every container (alt+1, alt+2, etc.)
Maybe ctrl+shift+t to open a tab in the current container, and ctrl+t to open a tab in the regular container.

[smichel17]

Maybe ctrl+shift+t to open a tab in the current container, and ctrl+t to open a tab in the regular container.

@imyxh is already taken; it opens the most recently closed tab.

[imyxh]

@smichel17 Oh. Right. I use that all the time, come to think of it.
Though I'm sure there's another substitute available, like Alt + T or Ctrl + Alt + T (though the latter opens a terminal in most distributions of Linux.)

[grahamperrin]

Alt-T = Tools menu (Firefox on KDE Plasma 4 on FreeBSD)

Points of reference that may be useful include:

• Mac keyboard shortcuts - Apple Support
• https://docs.kde.org/trunk4/en/kde-runtime/fundamentals/kbd.html – KDE Plasma™ 4 shortcuts
• https://docs.kde.org/stable5/en/kde-workspace/plasma-desktop/shortcuts.html – KDE Plasma Workspaces common keyboard shortcuts – "… the most common shortcuts supported by the workspace itself and many applications available within. Every application also provides its own shortcuts, so be sure to check their manuals for a comprehensive listing. …"
• in Ask Ubuntu, the accepted answer to Enabling native shortcuts on Gnome - 3

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

[lmorchard]

Not sure if this issue is progressing at all, but:

The real problem here is that we force the user to pick a context before they enter the URL.

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.

[smichel17]

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.

@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.)

[lelandbatey]

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 ctrl+t in a container tab Personal would open a tab in the default container, which is no container. Once the setting where enabled, if ctrl+t where entered in a Personal container tab, the newly created tab would also be a Personal container tab.

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?

[Symbai]

I would support the idea of it being optional instead of a new hotkey or its forced to anything.

[groovecoder]

Duplicate of #462 which has more up-votes. Please transfer any up-votes there (if you haven't already).

[Ithiloneth]

Tree Style Tab by Piro has a function that lets you automate this for opening a new tab.

It works for me with:

• Ctrl+t
• Scroll-wheel (middle mouse) click on link
• "+" button in Tree Style Tab
• And more I'm sure; only just now set this up as a solution to this issue

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.