fix(ui): lift portalled popups above app overlays - #611
Merged
Conversation
Base UI portals selects, menus, popovers and tooltips into <body>, where the Positioner — the element that actually paints — had `z-index: auto`. The `z-50` on the Popup inside it is scoped to the positioner's own stacking context and cannot lift the subtree, so any app overlay with a real z-index painted over the popup. That made the table view's column data-type selector unusable: the field menu's `z-40` scrim covered the open dropdown, and a click aimed at an option landed on the "Hide in view" button underneath it instead. Put the z-index on the positioner via a shared POPUP_LAYER, above the shell's overlay range (app overlays top out at z-[200], devtools at z-[10000]), so a dropdown opened from inside any of them stays clickable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: xNet Test <test@xnet.dev>
Contributor
🖼️ UI changes in this PRNo visual differences detected in the changed UI. |
Contributor
|
Preview removed for PR #611. |
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.
The bug
Opening a table column's ⋯ menu and trying to change its data type does nothing — the type dropdown renders behind the field popover, so its options can't be clicked.
Root cause
Base UI portals selects/menus/popovers/tooltips into
<body>. The element that actually paints is the Positioner, and it hadz-index: auto. Thez-50on thePopupinside it is scoped to the positioner's own stacking context and can't lift the subtree — so any app overlay with a real z-index wins.The field menu is exactly that: a
fixed inset-0 z-40scrim.40 > auto, so the scrim and its buttons paint over the open dropdown.Verified in the running app — with the positioner at
z-index: auto, a hit test at the centre of the open dropdown returns the popover's "Hide in view" button, not an option:The fix
Put the z-index on the positioner, via a shared
POPUP_LAYER(packages/ui/src/primitives/layers.ts), applied to every portalled positioner:Select,Menu,Popover,Tooltip,ContextMenu. The value sits above the shell's whole overlay range (app overlays top out atz-[200], devtools atz-[10000]), so a dropdown opened from inside a scrim, modal, or devtools panel stays clickable.This is systemic, not just the table view — a select inside a modal failed identically.
Verification
/app?demo=1→ CRM Accounts), opened the Stage column's ⋯ menu, and changed its type from Single select → Text end-to-end. Dropdown paints over the popover.packages/ui/src/primitives/layers.test.tsx: the open dropdown's positioner carriesPOPUP_LAYER, and the layer sits above every shell overlay.tsc --noEmitclean for@xnetjs/ui; primitive tests pass; prettier clean.No changeset —
@xnetjs/uiis private. Changelog fragment included.🤖 Generated with Claude Code