Description
When EuiFlyout uses type="push", the decision to render as push vs overlay is driven by pushMinBreakpoint and EUI’s useIsWithinMinBreakpoint. That hook compares the viewport / window to the theme breakpoint, not the width of the element passed via the container prop.
As a result, a flyout scoped to a narrow panel can still use push mode if the browser window is wide enough, and a flyout in a wide embedded area can still flip to overlay if the window is below the breakpoint—even though the available space for the container would suggest the opposite.
Context
Implementation (current @elastic/eui):
optimize/es/components/flyout/hooks.js — useIsPushed uses useIsWithinMinBreakpoint(pushMinBreakpoint) and documents behavior as based on window size.container is used for padding targets, positioning, and measuring containerRect / containerDimensions, but not for the push/overlay breakpoint decision.
This matters for Kibana layouts where flyouts are container-scoped (e.g. dashboard-style or inset app areas) and product logic assumes “narrow panel ⇒ overlay”.
Current behavior
pushMinBreakpoint / push vs overlay: viewport-based only.
Proposed behavior
When container is set (or possibly when using the flyout manager’s container), evaluate push vs overlay against the container’s width (e.g. via existing resize observation already used for containerDimensions), or document a supported pattern (e.g. container queries) so behavior matches usable width for that flyout.
Fallback when container is unset should remain window-based for backward compatibility.
Impact
- More predictable UX for inset / container-scoped flyouts across Kibana.
- Likely requires a change in Elastic UI (
@elastic/eui); this issue tracks the Kibana-side need and dependency upgrade once upstream ships.
References
- Related investigation: push flyouts,
pushMinBreakpoint, chrome --euiPushFlyoutOffsetInlineEnd overrides in Kibana layout.
Description
When
EuiFlyoutusestype="push", the decision to render as push vs overlay is driven bypushMinBreakpointand EUI’suseIsWithinMinBreakpoint. That hook compares the viewport / window to the theme breakpoint, not the width of the element passed via thecontainerprop.As a result, a flyout scoped to a narrow panel can still use push mode if the browser window is wide enough, and a flyout in a wide embedded area can still flip to overlay if the window is below the breakpoint—even though the available space for the container would suggest the opposite.
Context
Implementation (current
@elastic/eui):optimize/es/components/flyout/hooks.js—useIsPushedusesuseIsWithinMinBreakpoint(pushMinBreakpoint)and documents behavior as based on window size.containeris used for padding targets, positioning, and measuringcontainerRect/containerDimensions, but not for the push/overlay breakpoint decision.This matters for Kibana layouts where flyouts are container-scoped (e.g. dashboard-style or inset app areas) and product logic assumes “narrow panel ⇒ overlay”.
Current behavior
pushMinBreakpoint/ push vs overlay: viewport-based only.Proposed behavior
When
containeris set (or possibly when using the flyout manager’s container), evaluate push vs overlay against the container’s width (e.g. via existing resize observation already used forcontainerDimensions), or document a supported pattern (e.g. container queries) so behavior matches usable width for that flyout.Fallback when
containeris unset should remain window-based for backward compatibility.Impact
@elastic/eui); this issue tracks the Kibana-side need and dependency upgrade once upstream ships.References
pushMinBreakpoint, chrome--euiPushFlyoutOffsetInlineEndoverrides in Kibana layout.