fix: hoist floating overlays into shell so they share a stacking cont…#1203
Merged
fix: hoist floating overlays into shell so they share a stacking cont…#1203
Conversation
…ext with render overlays `.dv-dockview` has `contain: layout`, which forms a stacking context. That trapped floating overlay z-indexes inside `.dv-dockview` and prevented them from stacking against the OverlayRenderContainer's `.dv-render-overlay` panels (which live at the shell level). The visible symptom was that a floating panel using `renderer: 'always'` would always appear above other floating panels regardless of which group was active — the `AriaLevelTracker` ordering was correct, but the two layers were resolving in different stacking contexts. Add a `.dv-floating-overlay-host` element in the shell, sized to mirror the gridview rect on each layout. Floating overlays now live inside this host alongside the render overlays, so all overlay z-indexes resolve in the same shell-level stacking context and the `AriaLevelTracker` is the single source of truth for layering. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
18 tasks
pull Bot
pushed a commit
to bryanwills/dockview
that referenced
this pull request
Apr 28, 2026
The `.dv-floating-overlay-host` introduced in mathuo#1203 has `pointer-events: none` so it doesn't block clicks on the gridview underneath, but nothing re-enabled pointer events on the floating overlay inside it — so clicks and drags on a floating group passed straight through and the group became uninteractable. Set `pointer-events: auto` on `.dv-floating-overlay-host > .dv-resize-container`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
pull Bot
pushed a commit
to bryanwills/dockview
that referenced
this pull request
Apr 28, 2026
After mathuo#1203 floating overlays live in the shell as siblings of the popover anchor, sharing one stacking context. AriaLevelTracker writes their inline z-index as `calc(999 + i*2)`; for a single floating group that equals the popover's `var(--dv-overlay-z-index)` (999), so the later-in-DOM `dv-floating-overlay-host` paints over the menu and right-clicking a tab inside a floating group appeared to do nothing. Mirror the lookup that `tabsContainer` already does for its overflow popover: walk up from `event.target` via `findRelativeZIndexParent` and pass `calc(<that> * 2)` so the menu always sits above the overlay it was opened from. Apply to both `show()` (tab menu) and `showForChip()` (chip menu). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
…ext with render overlays
.dv-dockviewhascontain: layout, which forms a stacking context. That trapped floating overlay z-indexes inside.dv-dockviewand prevented them from stacking against the OverlayRenderContainer's.dv-render-overlaypanels (which live at the shell level). The visible symptom was that a floating panel usingrenderer: 'always'would always appear above other floating panels regardless of which group was active — theAriaLevelTrackerordering was correct, but the two layers were resolving in different stacking contexts.Add a
.dv-floating-overlay-hostelement in the shell, sized to mirror the gridview rect on each layout. Floating overlays now live inside this host alongside the render overlays, so all overlay z-indexes resolve in the same shell-level stacking context and theAriaLevelTrackeris the single source of truth for layering.Description
Type of change
Affected packages
dockview-coredockview(vanilla JS)dockview-reactdockview-vuedockview-angulardocsHow to test
Checklist
yarn lint:fixpassesyarn formatpassesnpm run genhas been run and generated files are up to dateyarn testpasses