cmux NEXT: a new window lists only its own sidebar groups

Merged
AU
10d ago
+225-14

Fixes #25776

What

In cmux NEXT, Cmd+Shift+N opened a window whose sidebar listed every group of the other windows, each empty ("No workspaces · drag one here"). Now a new window lists only its own groups and workspaces, as cmux classic does: a group belongs to the window that lists its workspaces.

Why it happened

  • SidebarDocProjection.arrange puts each Pinned or custom-section group in its section. A group the window did not list came back as emptyGroup, whatever held its workspaces. So every such group from another window showed empty in the new one.
  • The window filter (SidebarSection.filter) applied the rule to flat groups only. It kept a parent whose subgroups' workspaces another window lists, and a group with link members next to workspaces that list elsewhere.

Fix

  • The projection now records, for each band group, whether it holds an open workspace (a member row that is not a closed, dimmed one). arrange adds the empty header only when no group in that tree holds an open workspace. A saved group whose members all closed still shows its header everywhere.
  • SidebarSection.filter keeps a group when its tree holds a member in this window, or holds no workspace at all (empty groups and link-only groups belong to no window, so every window can still drop into them).

Tests

SidebarNewWindowGroupsTests (new):

  • aNewWindowListsNoGroupOfAnotherWindow: a window listing only its own workspace gets no band group from another window. The saved group whose only member closed is the one that stays.
  • theOwningWindowKeepsItsGroups: the window that lists the members keeps every group, including a nested parent.
  • theWindowFilterDropsGroupsWhoseWorkspacesListElsewhere: nested parent, group with links, empty group, link-only group, this window's group.

Command: cmux-ci run --class light --script scripts/ci/package-test-lane.sh --env CMUX_CI_XCODE_APP=/Applications/Xcode_26.6.app --arg=suite --arg=Packages/macOS/CmuxNext --arg=<suites>

  • Base + test (cd88b9f0ecb, step e88539511d3fcb6aed6e7aec, cmuxs-Mac-mini-3): failed. aNewWindowListsNoGroupOfAnotherWindow listed [itm_gs, itm_ga, itm_gp, itm_gk] where it expected [itm_gs], and the filter test kept parent and linked.
  • Head (75a1001fac97b665cd3ba1725cf416ee1b8f5752, step b14dd0d4c4e0ed2b1e7d69b8, aws-m4pro-4): all 8 suites passed: SidebarNewWindowGroupsTests, SidebarRowsOwnershipRedrawTests, SidebarDocArrangeIdempotenceTests, SidebarDocArchiveTests, SidebarDragKeepsGroupsTests, SidebarLayoutWindowScopeTests, SidebarEmptyGroupTests, SidebarClickMovesNoRowTests.

Observed / Not run

Observed: the red and green fleet runs above; prepush-gate.py reported no new violations; the dev build at the head (job f9cc20476e2fc5c26dd1c6d5, tag 25776-new-window-groups) built and published; three correctness review rounds (FIX, FIX, then SHIP at the head; findings in the PR comments).

Not run: I did not drive the dev build through Cmd+Shift+N with two windows myself. The bridge wiring that computes elsewhere in SidebarBridge.show is verified by reading the code; only SidebarRows is unit-tested. Release compile and the full CmuxNext suite are left to CI.

Behaviour changes beyond the issue: a group whose workspaces another window lists no longer shows in this window together with its link members. A saved group with no open member, an empty group and a link-only group still list everywhere.

Changelog

Fixed: A new window (Cmd+Shift+N) no longer lists other windows' sidebar groups as empty groups.

No capture: the bug needs two windows that share sidebar groups, and no capture scene sets that up. The new and changed tests cover the listing, and the tagged dev build 25776-new-window-groups is there for a hands-on check.

🤖 Generated with Claude Code