Context
Reported by @tobiu 2026-09-01 against the Workstation on dev@2f8fc79792: "Pop-out => grab the popup header, move it around => ZERO drop zone previews. does only re-integrate on close. REALLY REALLY bad."
He also corrected two wrong readings of mine before this ticket existed, and both corrections shape its scope:
- I claimed cross-window previews were unbuilt and pointed at #17578. Wrong — they work and are e2e-proven.
- I then claimed this was an unfiled
G3 lane on epic #15239. Also wrong — the feature is implemented.
Live latest-open sweep at 2026-09-01T17:29Z plus a Memory Core sweep (query_summaries) over the popup/cross-window decision space, which is what surfaced the prior art my issue-title greps had missed.
Why it works in the tests but not by hand
The proven path is test/playwright/e2e/workstation/WorkstationHumanPopupOverlapNL.spec.mjs (video mode: NEO_FILM_TAKE=1, "replays the identical assertions with on-glass compositing"). It asserts, at :1017 and :1026, "target choices remain visible" and "target preview remains visible beside proxy".
Its own contract explains why that does not cover the reported gesture:
"Every gesture input is Playwright's trusted page.mouse stream. CDP only controls physical native window bounds so the matrix is deterministic."
"CDP is deliberately only the physical-window adapter; no gesture or dock semantic rides it."
So every existing arm drives the pointer path and merely stages window positions. The reported gesture is the only one that goes through DragCoordinator#onWindowPositionChange (src/manager/DragCoordinator.mjs:1034) — whose JSDoc says it exists precisely for this:
"Handles geometry updates for native OS-titlebar popup reintegration... where the browser does not emit pointer move/up events. The current candidate target renders continuous hover preview per update; a terminal detached popup reintegrates only after it remains over a remote dashboard target long enough to satisfy the settle/dwell intent contract."
This is an implemented feature with zero end-to-end coverage. That is the defect's root condition: nothing exercises it, so nothing caught its regression.
Root cause (measured 2026-09-01, supersedes the earlier branch table)
Neo.main.addon.WindowPosition arms its 20ms movement poll on one signal only: a mouseout whose toElement is null, the event a pointer produces when it travels from page content onto the OS titlebar. The header-action pop-out births the vessel with its titlebar directly under the pointer that clicked the action, so the hand grabs the titlebar without the cursor ever entering popup content. No mouseout fires in the popup realm, the poll never arms, no geometry is published. manager.Window keeps the birth rect, the candidate hit-test reads a stationary centre, nothing previews, and reintegration is reachable only through the close path, which needs no geometry.
Three arms of one probe on dev@0659b0e42d, identical except for the trigger (CDP Browser.setWindowBounds as the physical-window adapter, four steps onto the main window's centre):
| trigger in the popup realm |
poll armed |
manager.Window follows |
previews per step |
| none — titlebar grabbed from outside content |
no |
no |
0 · 0 · 0 · 0 |
synthetic mouseout, no toElement (my earlier probes) |
yes |
yes |
0 · 0 · 0 · 1 → reintegration |
| real CDP pointer enters content, leaves through the top edge |
yes |
yes |
0 · 0 · 1 · 1 → vessel closed |
Downstream control in the failing arm: one direct publishGeometry() afterwards moved the manager rect to the live screen position, so the publish path and onWindowPositionChange are intact. Branches 1–3 of the original table never execute because onWindowPositionChange is never called; branch 4 was "cleared" only under a synthetic trigger the human gesture does not produce. The pointer-path specs never saw this because WorkstationHumanPopupOverlapNL calls publishGeometry() by hand after every CDP move, and a pointer tear-out always crosses popup content before the titlebar. A probe that supplies the trigger cannot test whether the trigger occurs.
Full measurement trail: the root-cause comment below (2026-09-01).
Acceptance Criteria
Out of Scope
- Maximize arming order (#18027).
lock remaining opt-in — a stated #18014 decision, not a defect.
- Multi-display behaviour:
window.moveTo is unpermissioned across displays, per the D#15204 audit.
Refs #17836 · #15239 · #18014
Context
Reported by @tobiu 2026-09-01 against the Workstation on
dev@2f8fc79792: "Pop-out => grab the popup header, move it around => ZERO drop zone previews. does only re-integrate on close. REALLY REALLY bad."He also corrected two wrong readings of mine before this ticket existed, and both corrections shape its scope:
G3lane on epic #15239. Also wrong — the feature is implemented.Live latest-open sweep at 2026-09-01T17:29Z plus a Memory Core sweep (
query_summaries) over the popup/cross-window decision space, which is what surfaced the prior art my issue-title greps had missed.Why it works in the tests but not by hand
The proven path is
test/playwright/e2e/workstation/WorkstationHumanPopupOverlapNL.spec.mjs(video mode:NEO_FILM_TAKE=1, "replays the identical assertions with on-glass compositing"). It asserts, at:1017and:1026, "target choices remain visible" and "target preview remains visible beside proxy".Its own contract explains why that does not cover the reported gesture:
So every existing arm drives the pointer path and merely stages window positions. The reported gesture is the only one that goes through
DragCoordinator#onWindowPositionChange(src/manager/DragCoordinator.mjs:1034) — whose JSDoc says it exists precisely for this:This is an implemented feature with zero end-to-end coverage. That is the defect's root condition: nothing exercises it, so nothing caught its regression.
Root cause (measured 2026-09-01, supersedes the earlier branch table)
Neo.main.addon.WindowPositionarms its 20ms movement poll on one signal only: amouseoutwhosetoElementis null, the event a pointer produces when it travels from page content onto the OS titlebar. The header-action pop-out births the vessel with its titlebar directly under the pointer that clicked the action, so the hand grabs the titlebar without the cursor ever entering popup content. Nomouseoutfires in the popup realm, the poll never arms, no geometry is published.manager.Windowkeeps the birth rect, the candidate hit-test reads a stationary centre, nothing previews, and reintegration is reachable only through the close path, which needs no geometry.Three arms of one probe on
dev@0659b0e42d, identical except for the trigger (CDPBrowser.setWindowBoundsas the physical-window adapter, four steps onto the main window's centre):manager.Windowfollowsmouseout, notoElement(my earlier probes)Downstream control in the failing arm: one direct
publishGeometry()afterwards moved the manager rect to the live screen position, so the publish path andonWindowPositionChangeare intact. Branches 1–3 of the original table never execute becauseonWindowPositionChangeis never called; branch 4 was "cleared" only under a synthetic trigger the human gesture does not produce. The pointer-path specs never saw this becauseWorkstationHumanPopupOverlapNLcallspublishGeometry()by hand after every CDP move, and a pointer tear-out always crosses popup content before the titlebar. A probe that supplies the trigger cannot test whether the trigger occurs.Full measurement trail: the root-cause comment below (2026-09-01).
Acceptance Criteria
page.mousegesture — and asserts a drop-zone preview renders in the target realm while the popup is over it. It must fail on currentdev.Object.keys()on aMapdoes not count.WorkstationHumanPopupOverlapNL(all matrix cells) andDemoBCrossWindowDragNLare unaffected.previewToOperation()→ commit.Out of Scope
lockremaining opt-in — a stated #18014 decision, not a defect.window.moveTois unpermissioned across displays, per the D#15204 audit.Refs #17836 · #15239 · #18014