fix: command-mode highlight wraps the full pane for browser surfaces#164
Merged
Conversation
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>
Deploying mouseterm with
|
| Latest commit: |
6b8441d
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://f80c5814.mouseterm.pages.dev |
| Branch Preview URL: | https://fix-browser-pane-command-mod.mouseterm.pages.dev |
dormouse-bot
approved these changes
Jun 20, 2026
This was referenced Jun 21, 2026
tend-mention: no-op session on bot's own APPROVED review of human PRs (upstream filing request)
#168
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Open a blank Dormouse, run
dor ab open example.com(from a terminal you've typed in, so it splits), then enter command mode: the selection highlight around the browser pane was the wrong size and shape — ~30px short and shifted down — instead of wrapping the whole pane like a terminal's highlight does.Root cause
Browser surfaces use dockview's
renderer:'always'(required so the screencast canvas/iframe isn't moved on activation). That mounts the panel body in adv-render-overlaylayer that is a sibling of thedv-groupviewelements and sits only over the content area, below the ~30px tab header.resolvePaneElementresolves pane bounds by climbing to the nearest[class*="groupview"]ancestor. For terminals the body lives inside the groupview, so the climb finds the full group. For browser panes the climb finds nothing and falls back to the shorter overlay body — so the marching-ants highlight excluded the header strip.Measured live: browser overlay
{y:63, h:487}(body) vs. the full group{y:36, h:511}; a terminal in the same split gets{y:33, h:517}after inflation. The fix makes the browser highlight identical:{y:33, h:517}.Fix
Add
resolvePaneGroupElement(api, id, paneElements), which prefers the panel's authoritativegroup.element(thedv-groupview, correct for either renderer) and climbs the DOM only as a fallback for transient states where the panel isn't in the api yet. Resolved at measure-time, so it stays correct across re-parenting.Routed the three consumers of the old resolution through it (same root cause):
WorkspaceSelectionOverlay— the reported command-mode highlightfindReattachNeighbor/findPaneInDirection— arrow-key spatial nav and door reattachKillConfirmOverlay— modal centered over the pane being killedSkill doc
Also documents in the
debug-standalone-agent-browserskill thatdorcommands must be typed into the Dormouse instance under test, never run from your own shell — otherwisedorinherits the installed app'sDORMOUSE_SURFACE_ID/control-socket env and targets the wrong instance, and an externally-rundorlacks caller-surface context (changing split-vs-replace behavior).Verification
spatial-nav.test.ts(5 cases: api group preferred, DOM-climb fallback, null api, disconnected group, no panel).tscclean.🤖 Generated with Claude Code