ui: expose container portal prop on all overlay Popup components#77163
Conversation
74827e1 to
530f6d2
Compare
|
Size Change: 0 B Total Size: 7.74 MB ℹ️ View Unchanged
|
|
Flaky tests detected in 4db3fcb. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24250192586
|
530f6d2 to
3899807
Compare
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Add a `container` prop to Dialog.Popup, AlertDialog.Popup, Tooltip.Popup, and Select.Popup, forwarding it to the underlying Base UI Portal. This lets consumers render overlays into a custom DOM node (e.g. for z-index stacking contexts or iframe scenarios). Popover.Popup already has this prop from #76438. Made-with: Cursor
3899807 to
4db3fcb
Compare
What?
Follow up to #76438
Add a
containerprop to thePopupsubcomponent of Dialog, AlertDialog, Tooltip, and Select — matching what Popover already has from #76438.Why?
Consumers need to render overlays into custom DOM nodes (e.g. for z-index stacking contexts or iframe scenarios). Popover already supports this; the other overlays should too, for consistency.
How?
Each
Popupgains one optional prop forwarded to the underlying Base UI<Portal>:container— a parent element to render the portal into (default:<body>)Details
Affected components:
Dialog.Popup,AlertDialog.Popup,Tooltip.Popup,Select.Popup(form primitive).Popover.Popupalready has it.The future
Drawercomponent should follow the same pattern.keepMountedis intentionally deferred until a concrete use case arises.Testing Instructions
<body>)container; confirm the overlay renders inside itUse of AI Tools
Cursor + Claude Opus 4.6