no-bug: Reopen tabs in the destination Space's container when moving between Spaces - #14750
Open
joegoldin wants to merge 3 commits into
Open
no-bug: Reopen tabs in the destination Space's container when moving between Spaces#14750joegoldin wants to merge 3 commits into
joegoldin wants to merge 3 commits into
Conversation
joegoldin
marked this pull request as ready for review
July 28, 2026 05:17
dosubot
Bot
added
the
size:L
Contributor
Author
|
I've also been running this on my machine for a while without issues |
joegoldin
added a commit
to joegoldin/zen-browser-desktop
that referenced
this pull request
Jul 28, 2026
Upstream closed zen-browser#14751, so only zen-browser#14750 (container routing on Space move) is still open. Corrects the README and the branch model, which described feat/nix-flake as held off dev pending review that is not happening.
When moving a tab to another space, reopen it in that space's container (if one is set) instead of leaving it in the previous space's container. Adds reopenTabInWorkspaceContainerIfNeeded() and wires it into the context-menu 'move to space' action and the drag-and-drop drop-onto-space path. Also fix space routing so it honors a route's destination container even when that container is the default/no container (0): tabbrowser now keys off isRouteFound instead of the truthiness of userContextId, so a routed tab no longer inherits the active space's container.
The container indicator was driven by a static zenDefaultUserContextId attribute set at tab creation, so it only reflected the space a tab was born in. Once a space had a default container set, the marker never updated for tabs whose container differed from it. Recompute the marker dynamically against the active space's default container (on space change, when a space's container is reconfigured, and when tabs are moved/created), so a tab shows the marker whenever its container differs from the space's default. Container-less tabs in a space that has a default container get a neutral gray marker, since there is no container colour to show.
- Wrap an over-length condition so the file passes 'mach lint zen' (Prettier). - Restore selection to the original tab if reopening fails after selection already moved to the new tab, before discarding it. - Correct the comment on the post-workspace-switch indicator refresh: it runs on every space switch, not only when the default container changes.
joegoldin
force-pushed
the
feat/space-container-routing
branch
from
July 29, 2026 04:43
7a0a610 to
661b44f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this fixes
Moving a tab into a Space that has a default container left the tab in its old container. The tab now sits in a Space whose container it doesn't belong to, and nothing in the UI says so, because the container marker was decided once at tab creation and never recomputed.
Two changes: move the tab into the destination Space's container, and make the marker reflect the Space you're actually looking at.
Reopening in the destination container
Firefox can't change a tab's
userContextIdin place, so the tab has to be reopened.reopenTabInWorkspaceContainerIfNeeded()copies the tab's SessionStore state (URL, full session history, pinned state), sets the new container and Space on the copy, restores it, and closes the original. Selection follows the tab, and a tab that wasn't selected is recreated lazily so moving a batch of background tabs doesn't force a load.It returns the original tab untouched when there's nothing to do: the destination Space has no default container, the tab is already in that container, or the tab is one whose DOM relationships would break if it were recreated (essentials, the empty-tab placeholder, glance tabs, and members of a split-view group). If the reopen throws partway through, selection is put back on the original tab and the half-built replacement is discarded, so a failure costs you nothing.
Both paths that move tabs between Spaces use it: the tab context menu's "move to Space" action, and dropping a tab onto a Space in the sidebar.
One incidental change in
changeTabWorkspace: the tab to select afterwards is now read beforemoveTabsToWorkspacerather than after. That function reverses its argument array in place whenzen.view.show-newtab-button-topis set, which defaults to true, so reading afterwards picked the first of a multi-tab selection instead of the last. Single-tab moves, the common case, are unaffected.Making the container marker mean something
The marker was driven by a
zenDefaultUserContextIdattribute written when the tab was created, so it only ever described the Space the tab was born in. Once a Space had a container configured, tabs whose container differed from it showed nothing.updateTabContainerIndicators()now recomputes the marker for the active Space's tabs against that Space's default container, and runs whenever the reference container can change: on Space switch, when a Space's container is reconfigured, and when tabs are added or moved. A tab shows the marker when its container differs from the Space default and hides it when they match.Container-less tabs needed a separate case. Firefox only colours the marker when a tab has a
userContextId, so a tab with no container sitting in a Space that does have one would render nothing at all, which is exactly the case the user needs to see. Those get azen-neutral-container-markerattribute and a gray marker, since there's no container colour to borrow.Testing
Built against Firefox 153. This branch adds no automated tests; the behaviour is exercised through the Space Routing suite, which covers the container resolution it builds on.