Context
Found in manual testing of apps/workstation on dev (2026-10-22), in the same pass as #19982, #19984 and #19985. @tobiu's screenshot, which follows in a comment, shows a maximized pane mid tab-drag inside its own header. Two things in it are wrong:
- A teal frame that ends part-way down the pane. It looks like a cut-off focus outline. It is the dock's drop preview for the layout behind the maximized pane.
- The header actions render as
× _ ⋯. ⋯ (More tabs) sits last, while the frozen header order puts it first.
Measurements
Headless Chromium at 8bb3574d0f (its src/, apps/ and resources/scss/ are identical to dev at 84b711878a). Gesture: maximize the shipped layout's 12-tab pane, activate a tab so the header re-partitions (#19982), then drag "Command and Control Console" 600 px left within the header and release. Docked control: a 2000×900 viewport, dragging "Priority Alert Observatory" 150 px right within its strip.
|
docked |
maximized (1440×900) |
| preview while dragging |
neo-dock-preview-tab-into over the pane itself [1125,121,1691,707] |
neo-dock-preview-edge-top neo-dock-preview-accepted neo-dock-preview-region neo-dock-preview-cut-bottom over the workspace's top edge band [0,109,1440,505], with a 2px teal border. This is the frame in the screenshot. |
| after release |
tabs reordered in place |
neo-dock-maximized is gone, and the pane is back at its docked rect [808,121,1188,707]. There are still 6 tabs nodes, and the dragged tab is the active tab of the same node. |
So an in-strip reorder of a maximized pane targets the workspace edge behind the maximized plane, and releasing it un-maximizes the pane.
The ⋯ reversal is not reproduced headless. I replayed three paths: a fresh 1440 px page; first clicking ⋯ (#19984's path) and refocusing the body; and 2000 px, where all 12 tabs fit and no ⋯ exists. In all three the DOM and visual order stayed spacer, ⋯, [gated actions], restore, close. It is recorded here as operator-observed, mid-drag, with the edge preview active.
The Problem
Maximize's own input contract is not enforced on the dock's cross-zone path. It suppresses the maximized node's strip SortZone with allowOverdrag: false, boundaryContainerId: <bar> and enableProxyToPopup: false. Those configs bound the strip's proxy, and none of them reaches the dock's targeting.
Neo.dashboard.dock.interaction.TabSortZone#onDragMove engages the cross-window dragCoordinator, and after the base sort fires dockCrossZoneDragMove with the pointer, on every move. Nothing checks whether the source node is maximized. The workspace then resolves the pointer against the docked layout under the maximized plane.
A maximized header sits inside the dock host's top-edge activation band. Its own in-strip gesture therefore reads as "dock to the top edge", and that target is accepted. On release the commit is classified as an operation beyond the node, which clears maximize terminally.
The strip had its own drag logic before dock layouts existed. On this gesture it overlaps the dock's pane-drag logic, and a maximized pane exposes the overlap.
The Architectural Reality
src/dashboard/dock/plugin/Maximize.mjs: suppressDragSources() snapshots and flips the three strip-zone configs; the restore path puts them back.src/dashboard/dock/interaction/TabSortZone.mjs onDragMove(): the coordinator engagement is gated on sortGroup and a live proxyRect, and dockCrossZoneDragMove is unconditional. Neither consults maximize.- Design authority:
Maximize's @summary. "in-strip tab reordering stays live; cross-zone drag sources and tear-out affordances of the maximized node are suppressed (every drop target sits under the maximized plane)", and operations confined to the node, "reordering … within it" included, "defer to the re-projection rule instead, which re-applies onto the surviving node".
The Fix
Let Maximize own the whole gate, as its @summary says. While a node is maximized, drags that start in its strip produce no cross-zone targeting:
TabSortZone engages the coordinator and fires dockCrossZoneDragMove only while its zone allows cross-zone drags.Maximize#suppressDragSources() turns that off next to the three configs it already flips, and its restore path restores it from the same snapshot.
The in-strip reorder then commits through the strip's own sort, a node-confined operation, so maximize survives under the existing re-projection rule.
Acceptance Criteria
Out of Scope
- Tearing a tab out of a maximized pane, which the contract already suppresses.
- #19982's stale partition after maximize. The spec activates a tab first, as the operator did, and does not depend on #19982.
- Other overlaps between the strip's drag logic and the dock's pane drags in docked panes. They are not observed here.
Related
Live latest-open sweep: checked latest 20 open issues at 2026-10-22T09:38:09Z; no equivalent found.
Keyword sweep: "maximized tab drag preview", "dockCrossZoneDragMove", "maximize drag edge preview", "tab reorder maximized"; closed adjacent only (#18471, Group operations clearing maximize, fixed by #18472; #18027).
A2A claim sweep: no overlapping lane-claim.
MC sweep: "tab drag inside maximized dock pane shows drop preview behind it…", 6 results, no prior decision.
Own-assignment sweep: none overlapping.
Origin Session ID: 70e59a84-efd6-4e7a-9262-c5478bd314ff
Retrieval Hint: "maximized dock pane tab reorder shows edge-top drop preview, dockCrossZoneDragMove ignores maximize, Maximize suppressDragSources"
Context
Found in manual testing of
apps/workstationondev(2026-10-22), in the same pass as #19982, #19984 and #19985. @tobiu's screenshot, which follows in a comment, shows a maximized pane mid tab-drag inside its own header. Two things in it are wrong:× _ ⋯.⋯(More tabs) sits last, while the frozen header order puts it first.Measurements
Headless Chromium at
8bb3574d0f(itssrc/,apps/andresources/scss/are identical todevat84b711878a). Gesture: maximize the shipped layout's 12-tab pane, activate a tab so the header re-partitions (#19982), then drag "Command and Control Console" 600 px left within the header and release. Docked control: a 2000×900 viewport, dragging "Priority Alert Observatory" 150 px right within its strip.neo-dock-preview-tab-intoover the pane itself[1125,121,1691,707]neo-dock-preview-edge-top neo-dock-preview-accepted neo-dock-preview-region neo-dock-preview-cut-bottomover the workspace's top edge band[0,109,1440,505], with a 2px teal border. This is the frame in the screenshot.neo-dock-maximizedis gone, and the pane is back at its docked rect[808,121,1188,707]. There are still 6 tabs nodes, and the dragged tab is the active tab of the same node.So an in-strip reorder of a maximized pane targets the workspace edge behind the maximized plane, and releasing it un-maximizes the pane.
The
⋯reversal is not reproduced headless. I replayed three paths: a fresh 1440 px page; first clicking⋯(#19984's path) and refocusing the body; and 2000 px, where all 12 tabs fit and no⋯exists. In all three the DOM and visual order stayedspacer, ⋯, [gated actions], restore, close. It is recorded here as operator-observed, mid-drag, with the edge preview active.The Problem
Maximize's own input contract is not enforced on the dock's cross-zone path. It suppresses the maximized node's stripSortZonewithallowOverdrag: false,boundaryContainerId: <bar>andenableProxyToPopup: false. Those configs bound the strip's proxy, and none of them reaches the dock's targeting.Neo.dashboard.dock.interaction.TabSortZone#onDragMoveengages the cross-windowdragCoordinator, and after the base sort firesdockCrossZoneDragMovewith the pointer, on every move. Nothing checks whether the source node is maximized. The workspace then resolves the pointer against the docked layout under the maximized plane.A maximized header sits inside the dock host's top-edge activation band. Its own in-strip gesture therefore reads as "dock to the top edge", and that target is accepted. On release the commit is classified as an operation beyond the node, which clears maximize terminally.
The strip had its own drag logic before dock layouts existed. On this gesture it overlaps the dock's pane-drag logic, and a maximized pane exposes the overlap.
The Architectural Reality
src/dashboard/dock/plugin/Maximize.mjs:suppressDragSources()snapshots and flips the three strip-zone configs; the restore path puts them back.src/dashboard/dock/interaction/TabSortZone.mjsonDragMove(): the coordinator engagement is gated onsortGroupand a liveproxyRect, anddockCrossZoneDragMoveis unconditional. Neither consults maximize.Maximize's@summary. "in-strip tab reordering stays live; cross-zone drag sources and tear-out affordances of the maximized node are suppressed (every drop target sits under the maximized plane)", and operations confined to the node, "reordering … within it" included, "defer to the re-projection rule instead, which re-applies onto the surviving node".The Fix
Let
Maximizeown the whole gate, as its@summarysays. While a node is maximized, drags that start in its strip produce no cross-zone targeting:TabSortZoneengages the coordinator and firesdockCrossZoneDragMoveonly while its zone allows cross-zone drags.Maximize#suppressDragSources()turns that off next to the three configs it already flips, and its restore path restores it from the same snapshot.The in-strip reorder then commits through the strip's own sort, a node-confined operation, so maximize survives under the existing re-projection rule.
Acceptance Criteria
neo-dock-preview-edge-*, and no other node's preview. The strip's own reorder feedback still works.neo-dock-maximizedand the restore action stay).⋯→ focus-gated engine set → restore/close. This is a guard for the reversal; ondevit is not red in our replays.tab-intopreview and reorders.test/playwright/e2e/workstation/WorkstationMaximizeTabReorderNL.spec.mjs, maximizes the 12-tab pane, re-projects its header, and drags a header tab within the strip with a real pointer. Mid-drag it asserts no edge preview and the action order; after release it asserts maximize is kept and the reorder applied. It must be red ondev(edge-top preview present, pane un-maximized after release) and green with the fix. A docked arm stays green. It joins the hosted Workstation NL tier (#19655).Out of Scope
Related
Live latest-open sweep: checked latest 20 open issues at 2026-10-22T09:38:09Z; no equivalent found. Keyword sweep: "maximized tab drag preview", "dockCrossZoneDragMove", "maximize drag edge preview", "tab reorder maximized"; closed adjacent only (#18471, Group operations clearing maximize, fixed by #18472; #18027). A2A claim sweep: no overlapping lane-claim. MC sweep: "tab drag inside maximized dock pane shows drop preview behind it…", 6 results, no prior decision. Own-assignment sweep: none overlapping.
Origin Session ID: 70e59a84-efd6-4e7a-9262-c5478bd314ff Retrieval Hint: "maximized dock pane tab reorder shows edge-top drop preview, dockCrossZoneDragMove ignores maximize, Maximize suppressDragSources"