fix(dockview-core): popout-window pointer drags + cross-group maximize focus#1371
Merged
Merged
Conversation
…e focus Two popout-window correctness niches surfaced while completing cross-window a11y. 1. Sash + scrollbar pointer drags were dead inside a popout. `splitview` and `scrollbar` attached their `pointermove`/`pointerup`/`pointercancel` (and the sash's `contextmenu`) listeners to the module-global `document` — the opener, not the popout — so a drag begun in a popped-out window was never heard. Bind the drag to the dragged element's own `ownerDocument` instead (also shields iframes in that document). Affects mouse users too, not just a11y. 2. Maximizing a *different* group than the focused one stranded focus on `<body>`: that group's DOM is hidden, blurring the focused element, and nothing pulled focus back. AccessibilityService already snapshots/restores focus across a `remove`; extend the same was-inside / not-inside guard to the `maximize` mutation. The guard means maximizing the focused group in place is still a no-op, so mouse users are never robbed of focus. Test: - module unit: maximize-into-another-group restores focus into the maximized group (jsdom can't blur a hidden element, so the hidden-element blur is emulated in the will phase; `setActive` doesn't move focus, so the focusContent spy isolates the restore). 108 modules green. - e2e `popout-pointer-drag.spec`: a sash dragged inside a popout resizes its split — only passes because the listeners now live on the popout document. - 1074 core green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…er-drag-and-maximize-focus # Conflicts: # e2e/fixtures/index.html # packages/dockview-modules/src/accessibilityService.ts
|
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
1 participant
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.
Summary
Two popout-window correctness niches found while completing cross-window accessibility (split out from the a11y PR per request — these are general bugs, not a11y-only).
1. Pointer drags dead inside a popout window
splitview(sash) andscrollbarattached theirpointermove/pointerup/pointercancel(and the sash'scontextmenu) listeners to the module-globaldocument— i.e. the opener, not the popout. A drag begun inside a popped-out window dispatched its move/up events in the popout's document, which the opener's listeners never heard, so resizing a split (and dragging a scrollbar) was dead in a popout.Fix: bind each drag to the dragged element's own
ownerDocument(and shield iframes in that document). This affects mouse users too, not just keyboard/a11y.2. Cross-group maximize stranded focus on
<body>Maximizing a different group than the focused one hides the focused group's DOM, blurring the focused element — and nothing pulled focus back.
AccessibilityServicealready snapshots/restores focus across aremove; this extends the same was-inside / not-inside guard to themaximizemutation. Because of that guard, maximizing the focused group in place stays a no-op, so a mouse user who maximizes is never robbed of focus.Test
Cross-document / hidden-element-blur behaviour isn't reachable in jsdom, so it's split between unit + the Playwright harness:
accessibilityDocking.spec, 108): maximizing another group restores focus into the maximized group. jsdom doesn't blur a hidden element, so the blur is emulated during thewillphase;setActivedoesn't move DOM focus, so thefocusContentspy isolates the restore.popout-pointer-drag.spec): a sash dragged inside a popout resizes its split — passes only because the listeners now live on the popout document. (Scrollbar shares the identical one-line fix.)Note
Targets
v8-branch(where the e2e harness lives). These are real v7 bugs too; can be cherry-picked tomasterif a v7 patch is wanted. TouchesaccessibilityService.ts, which PR #1368 also edits — expect a small merge resolution in that file whichever merges second.🤖 Generated with Claude Code