Update Container while switching tab to another workspace

[baxyz]

Captchas

• I have read the instructions.
• I have searched existing issues and avoided creating duplicates.
• I am not filing an enhancement request.
• I have checked that this issue cannot be reproduced on Mozilla Firefox.
• I have checked that this issue can be reproduced once I removed all my Mods and Custom CSS.

What happened?

Prerequisites

• Two or more workspaces, each associated with a different container.

Scenario

• Open a tab in one workspace.
• Switch this tab to another workspace.

Actual Behavior

The tab is successfully moved to the target workspace; however, it remains tied to the container of the previous workspace. In other words, the tab is simply relocated, but its container does not change.

This results in an inconsistent behavior: within the same workspace, two tabs with the same URL may behave differently because of the retained (and mismatched) container.

Problem Such behavior introduces incoherence and confusion for users who expect containers to align with the workspaces they switch to.

Expected Behavior

When a tab is switched from one workspace to another—particularly when this involves switching from one container to a different container—an optional popup should appear to inform the user that the tab will be reopened in the new container.

Ideally, this notification should be configurable in the settings, allowing users to enable or disable it according to their preferences.

Note: This scenario does not apply if the target workspace uses the same container as the original workspace.

Thank you for your consideration.

Version

1.11.1b

What platform are you seeing the problem on?

Linux (Flatpak)

What component is this issue related to?

Workspaces

Relevant log output if applicable

[Propheticus]

That would make workspaces too much 1:1 containers imho. Something can be said for it leading to less confusion perhaps, but you lose flexibility.

The fact a workspace has a default container that tabs that are opened there are assigned to does not mean that all tabs moved there should be switched to that container. The switch to another container would mean you lose your current session/view on that website, because the switch means a reload.
The different container can be recognised by the coloured marker left of the tab. (although Zen hiding this marker by default currently is confusing...)
It's a feature to be able to have the same site open in different containers with different sessions/accounts.

If you want to switch a tab to another container you can use "open in new container tab" and if you want it to then also switch workspace where that container is set as default you can use:

[baxyz]

You’re right—there’s undeniable value in the current flexibility offered by allowing tabs from different containers within the same workspace. I totally see how preserving individual sessions across containers is a crucial feature, especially for users who rely on juggling accounts or views seamlessly.

That said, the concept of "inclusion" (sorry, bad term) suggests there’s a hierarchy worth considering:

1. Workspaces each have a single default container, but can host tabs from multiple containers.
2. Containers can span multiple workspaces.

From this perspective, the flexibility provided by point 1 feels sufficient, and it avoids introducing unnecessary complexity into the user experience (UX).

The current behavior (you suggested) might work as intended, but it does lead to a UX conundrum: when moving a tab to another workspace, determining the “right container” to align with the workspace feels overly convoluted—like trying to untangle a knot that doesn’t need to exist in the first place.

If I’m honest, the behavior I suggested is somewhat inspired by Arc’s approach. While Arc doesn’t use containers, it operates on profiles containing workspaces, which is admittedly less flexible than what we have here.

Another argument to consider: for less technical users, the workspace concept takes precedence and is the centerpiece of the experience. It’s intuitive and central to how they interact with their tabs, meaning workspaces should be prioritized over containers in terms of user workflow and expectations.

To illustrate the use case: imagine opening an external tab from sources like Firefox Sync or your OS—it lands in the wrong workspace, but moving it to the right workspace ensures a neat organization or access to the correct accounts. That simple, neat alignment is what most users want, in my biased opinion.

Note: If this fix is applied, it will not remove the flexibility offered by point 1.

I hope this explanation adds some clarity to my original suggestion while acknowledging your valid points. Thanks again for the thoughtful discussion!

[Propheticus]

I see what you're getting at. Flexibility is nice, but too many possible permutations... can be confusing, convoluted, hard to mentally keep track of.
It's a fine line between a sane default that makes sense to newer users while still offering enough (configurable) room for those 'power user' usecases.
Having multiple intersecting concepts -workspaces, containers and soon tab folders/groups- leads to quite a Cartesian product. So perhaps you're right and a tighter workspace to container link would make sense to limit this at least somewhat.

[LeMoonStar]

This does not seem to be a bug report, but more of a feature request/change suggestion - and as such belongs into a Discussion, not an issue.

[baxyz]

From my point of view, it qualifies as a bug due to the current UX implementation. The behavior creates unexpected and inconsistent user experiences, which feels more like an unintended flaw rather than a deliberate design choice.

That being said, if it's better classified as a feature request on your end, I'm happy to proceed in that direction. 👍 Thanks.

[red-meadow]

I support this request. I've actually experienced the issue just now, while reading this conversation. My use case is the following:

I have a Personal and Developer workspaces, aligned with Personal and Developer containers. I'm searching and reading this discussion in Personal, where I'm not logged in to GitHub. I want to add my reaction and a comment. What can I do next:

Option 1. Open in New Container Tab > Developer.
Effect: the 2nd copy of the tab is created in my Personal workspace, in the Developer container.
Downsides:

• I have 2 copy of the same tab while I need only one, so I have to manually close the 1st one.
• If I want to pin the tab in my Developer workspace I still have to use Change Tab to Workspace > Developer.
• 3 steps in total to achieve what I need.

Option 2. Open in New Container Tab > Developer with Switch to workspace where container is set as default when opening container tabs setting enabled.
Effect: the 2nd copy of the tab is created in my Developer workspace, in the Developer container.
Downsides:

• The 1st copy stays in Personal, so I have to close it later.
• I have to think in terms of containers, while my actual intention is changing the workspace.
• If I have 2 or more workspaces sharing the Developer container, the "Switch to..." setting is ignored and the behavior is that from Option 1.
• 2 or 3 steps needed in total.

Option 3. Just copy the URL, close the tab, switch to the Developer workspace, open a new tab with a copied URL.
There are more steps to follow, but they can be done quickly using keyboard shortcuts.

My ideal solution would be to have a new setting Switch to workspace default container when changing tab(s) to workspace. Probably disabled by default, maybe with a warning about the session loss (right there in the settings). If it happens that a tab is already opened in the target container, it's moved without reloading and doesn't lose its state.

[ricardoboss]

This ^

In general, I think the context menu contains too many items. I would not want to add more. Instead, I'd like to change the behaviour of this context menu option:

It already moves the tab to the correct workspace, but doesn't change the profile. It's insane to me that I can even open a tab in a different profile other than the configured one for the workspace. This completely messes with my mental model.

[ricardoboss]

Maybe related issues for this:

• Workspaces working as tab groups and not as workspaces #7079
• Workspaces unlink/detach themselves from their respective Profiles/Containers #8983