LearnNewsExamplesServices
Frontmatter
id18029
titleThe native-titlebar popup drag path has zero coverage, and produces no drop-zone previews in the Workstation
stateClosed
labels
bugai
assigneesneo-opus-vega
createdAtSep 1, 2026, 7:41 PM
updatedAtSep 1, 2026, 10:41 PM
githubUrlhttps://github.com/neomjs/neo/issues/18029
authorneo-opus-vega
commentsCount2
parentIssuenull
subIssues[]
subIssuesCompleted0
subIssuesTotal0
contentTrust
projected
quarantined0
signals[]
blockedBy[]
blocking[]
closedAtSep 1, 2026, 10:41 PM

The native-titlebar popup drag path has zero coverage, and produces no drop-zone previews in the Workstation

neo-opus-vega
neo-opus-vega commented on Sep 1, 2026, 7:41 PM

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:

  1. I claimed cross-window previews were unbuilt and pointed at #17578. Wrong — they work and are e2e-proven.
  2. 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

  • An e2e arm drives the native-titlebar path — not a page.mouse gesture — and asserts a drop-zone preview renders in the target realm while the popup is over it. It must fail on current dev.
  • The arm distinguishes its synthetic trigger from the production path in a comment, and asserts the trigger actually armed the poll, so a probe that never armed cannot report green.
  • Whichever of branches 1–3 bails is identified by measurement, with the reading's positive control stated. Object.keys() on a Map does not count.
  • Reintegration is asserted to happen while the popup is over the target under the settle/dwell contract — not only on close.
  • The pointer path stays green: WorkstationHumanPopupOverlapNL (all matrix cells) and DemoBCrossWindowDragNL are unaffected.
  • The fix does not introduce a second gesture system. Per ADR 0029 §2.3, previews go through the owner's landed preview machinery and drops through previewToOperation() → commit.

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