You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: command-mode highlight wraps the full pane for browser surfaces
Browser surfaces use dockview's `renderer:'always'`, which mounts the panel
body in a `dv-render-overlay` layer that sits only over the content area, with
no `dv-groupview` ancestor. The selection/spatial code resolved pane bounds by
climbing to the nearest groupview, so for browser panes it fell back to the
shorter body — the command-mode marching-ants highlight was ~30px short and
shifted down instead of wrapping the whole pane like a terminal.
Add `resolvePaneGroupElement`, which prefers the panel's authoritative
`group.element` (correct for either renderer) and climbs the DOM only as a
fallback. Route the selection overlay, spatial navigation, and kill-confirm
overlay through it.
Also document in the debug-standalone-agent-browser skill that `dor` must be
typed into the Dormouse instance under test, not run from your own shell — it
otherwise inherits the installed app's surface/socket env and targets the wrong
instance.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
### Run `dor` by typing into Dormouse — never from your own shell
71
+
72
+
`dor` commands (`dor ab open`, `dor split`, …) must be **typed into the Dormouse terminal under test** (the xterm — see *Typing into xterm* and *Submitting (Enter)* below), exactly as a user would. Do **not** run the staged `dor` (or `node .../dor.js`) from your own shell, even if you point it at the harness's `DORMOUSE_CONTROL_SOCKET`/`DORMOUSE_CONTROL_TOKEN`. Two ways it breaks:
73
+
74
+
-**Wrong instance.** Your dev shell is often itself running *inside the installed Dormouse*, so it inherits that app's `DORMOUSE_SURFACE_ID`, `DORMOUSE_CONTROL_SOCKET`, and `DORMOUSE_CONTROL_TOKEN`. A bare `dor` then drives (or errors against) the **installed** app, not the harness — e.g. `Warning: could not open the Dormouse browser surface: surface '<stale-id>' was not found`.
75
+
-**Wrong / missing caller surface.**`dor` resolves its target from `DORMOUSE_SURFACE_ID` (the pane it runs in), then the focused surface. Typed into the xterm, that variable is the harness pane, so surface targeting *and the split-vs-replace behavior match real usage*: `dor ab open`**splits** next to a **touched** terminal but **replaces** an **untouched** one (`createContentSurface`'s `replaceUntouchedTerminal`). Any input into a terminal touches it, so a user who typed the command gets a split — but an externally-run `dor` leaves the terminal untouched (and has no caller pane), so you get a replace and the flow no longer matches what the user sees.
76
+
77
+
So to reproduce a user flow faithfully: `keyboard inserttext` the `dor …` line into the xterm, submit it with the synthetic Enter, then watch the harness log / DOM for the result.
78
+
70
79
### Command/mouse subcommands are limited
71
80
72
81
-`agent-browser keyboard` accepts only `type` and `inserttext` (there is **no**`keyboard press`).
0 commit comments