[EuiFlyout] Preserve pixel width on container resize when size is numeric

[clintandrewhall]

Summary

Closes #9969

What: A resizable EuiFlyout given a numeric size no longer rescales when the flyout container's width changes. It keeps the user's pixel width and is only re-clamped. Container-driven resizes also no longer fire onResize.

Why: When the container width changed, useEuiFlyoutResizable multiplied the current pixel width by the reference-width ratio to preserve the flyout's percentage of the container. For a type="push" flyout this moves both panes on a single container resize — the flyout rescales and the pushed content reflows to match.

Separately, callOnResize is set to true on onMouseUp/onKeyDown and was never reset on the constraint-change path, so these machine-generated rescales called onResize. Consumers that persist the callback value had the user's stored width permanently overwritten by a window resize.

How: Branch on the size type in the constraint-change path of use_flyout_resizable.ts, and reset callOnResize when the reference width actually changed.

setFlyoutWidth((currentWidth) => {
  if (currentWidth && prevRefWidth > 0 && _referenceWidth > 0) {
    // A numeric `size` is a pixel contract — re-clamp rather than rescale.
    if (typeof _size === 'number') {
      return getFlyoutMinMaxWidth(currentWidth);
    }
    const scaleFactor = _referenceWidth / prevRefWidth;
    return getFlyoutMinMaxWidth(currentWidth * scaleFactor);
  }
  ...

Why the fix is conditional, and why it does not conflict with #9683

#9683 fires on the same trigger — the flyout container's width changing — but asks for the opposite outcome: a manually-resized main+child pair should revert to its coded s/m size when it goes stacked. Both asks are valid because they describe different consumer contracts, and typeof size === 'number' is the discriminator:

size prop	Contract	Behavior on container resize
's' / 'm' / 'l' / 'fill'	Percentage semantics	Keeps scaling — unchanged by this PR
numeric (e.g. 544)	Consumer measured, persisted, and re-supplied pixels	Re-clamp only, preserve pixels

Scaling is correct for named sizes because EUI literally defines them as percentages in packages/eui/src/components/flyout/flyout.styles.ts:

s: width 25%
m: width 50%
l: width 75%
   (capped at 90%)

An m flyout that stays at 50% through a container resize is behaving as designed, and the pre-existing code comment said so explicitly ("preserves the flyout's percentage position in both directions"). Removing the scale factor unconditionally would be a silent semantic change for every resizable named-size flyout, and would pre-empt #9683's design space. This PR therefore changes the numeric branch only.

The test preserves the percentage for a named "size" in use_flyout_resizable.test.ts is the regression guard for that: it asserts an m flyout still holds 50% across a reference-width change. It passes both with and without this diff, which is exactly what a guard should do.

Notes for reviewers

• resizeMode prop deliberately not added. The issue floats an explicit resizeMode: 'pixel' | 'percent' prop as the more discoverable API. This PR implements the inferred (typeof size === 'number') version, which needs no consumer changes and keeps the diff reviewable. Happy to switch to the explicit prop if the team prefers it.
• The callOnResize reset is gated on the reference width having changed (if (_referenceWidth !== prevRefWidth)) rather than firing unconditionally. An unconditional reset in this branch would risk suppressing the legitimate onResize at the end of a drag when a sibling width or other clamp input changes around the same tick. There is a test covering that a drag-then-release still fires onResize exactly once with the final width.
• The % round-trip is lossless on this path. referenceWidth comes from useResizeObserver(container, 'width') (which reports borderBoxSize.inlineSize) and flyout.component.tsx converts back with containerRect.width from getBoundingClientRect() — both border-box. This PR does not change the % output mechanism.
• Known separate follow-up: the container.clientWidth fallback in flyout.component.tsx:365 (used when the ResizeObserver hasn't reported yet) is content-box where the rest of the path is border-box, so it is off by the container's padding on the first frame — including the push padding this component applies itself. That's a real but distinct bug and is intentionally not folded in here.

Reporting consumer

Kibana's Discover document details flyout. Kibana scopes flyouts to the app workspace container (#app-main-scroll), so a window resize, a sidebar resize, or opening the AI Assistant all change referenceWidth; Discover persists the onResize width to localStorage, which is the user-visible half of the bug. Kibana tracks its own consumer-side fixes (the ones that do not need this change) at elastic/kibana#287943.

API Changes

component / parent	prop / child	change	description
EuiFlyout / EuiFlyoutResizable	size (numeric)	Behavior	A numeric size is now treated as a pixel contract: on container resize the flyout is re-clamped rather than rescaled proportionally
EuiFlyout / EuiFlyoutResizable	onResize	Behavior	No longer called for container-driven (non-user) resizes

Screenshots

No visual change for named sizes. For numeric sizes the change is that the flyout stops moving on container resize; see the screenshot in #9969 for the reported behavior.

Impact Assessment

• 🔴 Breaking changes — None. No API surface changes; the behavior change is scoped to resizable flyouts with a numeric size.
• 💅 Visual changes — Only for resizable flyouts with a numeric size during a container resize, and in the direction the issue asks for. Named sizes (s/m/l/fill) are untouched.
• 🧪 Test impact — Added 6 unit tests. No existing test was changed: use_flyout_resizable.test.ts had no coverage of scaling on referenceWidth change (every prior test uses a static referenceWidth), so nothing was weakened to get green.
• 🔧 Hard to integrate — No consumer changes required.

Impact level: 🟢 Low

Release Readiness

• Documentation: no doc-visible API change
• Figma: n/a
• Migration guide: n/a
• Adoption plan (new features): bug fix; the reporting consumer is Discover

QA instructions for reviewer

1. Render a resizable EuiFlyout with type="push", a numeric size (e.g. 544), and a container element narrower than the viewport.
2. Drag the resize handle to a chosen width and note the pixel value.
3. Change the container's width (resize the window, or toggle a sidebar beside it).
   • Confirm the flyout stays at the dragged pixel width (re-clamped if it no longer fits within 90% of the container / maxWidth), and that only the pushed content resizes.
   • Confirm onResize does not fire for the container resize.
4. Repeat with size="m".
   • Confirm the m flyout still scales proportionally, holding 50% of the container across the resize (pre-existing behavior, deliberately preserved for [Flyout System] Resizable Flyout Issues #9683).
5. Drag-and-release on both.
   • Confirm onResize still fires exactly once with the final width.

Checklist before marking Ready for Review

• Filled out all sections above
• QA: Tested light/dark modes, high contrast, mobile, Chrome/Safari/Edge/Firefox, keyboard-only, screen reader — no rendering or styling change
• QA: Tested in CodeSandbox and Kibana
• QA: Tested docs changes — no docs changes
• Tests: Added Jest coverage (verified that the 4 new behavior tests fail against the unfixed hook, and that the 2 regression guards pass either way). Cypress: not added — the existing flyout_resizable.spec.tsx never passes a container and never changes the container width mid-test, so it does not exercise the branch this PR touches and is unaffected. A Cypress case that resizes a real container would be worthwhile, but I could not validate one in my environment (the Cypress binary host is unreachable there), so I left it out rather than push an unverified spec. Happy to add it on request.
• Changelog: added
• Breaking changes: Added breaking change label — not a breaking change

---

Generated by Claude Code

[cla-checker-service]

💚 CLA has been signed

[github-actions]

👋 Since this is a community submitted pull request, a Buildkite build has not been started automatically. Would an Elastic organization member please verify the contents of this pull request and kick off a build manually?

[Copilot]

🟡 Changes recommended

The callback reset can still allow container-driven onResize calls when the callback identity changes concurrently.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates resizable flyouts to preserve numeric pixel widths during container resizing.

Changes:

• Re-clamps numeric sizes while retaining proportional scaling for named sizes.
• Prevents most container-driven onResize callbacks.
• Adds regression tests and changelog entries.

File summaries

File	Description
use_flyout_resizable.ts	Implements conditional resize behavior.
use_flyout_resizable.test.ts	Tests resizing, clamping, and callbacks.
9976.md	Documents both fixes.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[weronikaolejniczak]

blocking:

It seems we introduced a regression. When we resize the window to small and then resize it back to big, the flyout stays the smaller width instead of the size we set.

[clintandrewhall]

@weronikaolejniczak you're right, and thanks for catching it — that was a real regression in this PR. Fixed in 17beead.

What was wrong. The numeric branch re-clamped the already-clamped flyoutWidth:

return getFlyoutMinMaxWidth(currentWidth);

which is lossy. With size={800} at a 1200px reference width, shrinking to 600px clamps to 540px (90%) — and that 540 then becomes the stored width. Growing back to 1200px re-clamps 540, which is already within bounds, so the flyout stays at 540. The original 800 was gone. Exactly what your screenshot shows.

The fix. Track the width that was requested separately from the width being rendered, and always clamp the request rather than the previous result:

const requestedWidthRef = useRef<number | null>(null);
...
if (typeof _size === 'number') {
  return getFlyoutMinMaxWidth(requestedWidthRef.current ?? _size);
}

Clamping is now non-destructive: the flyout narrows while there isn't room and returns to the requested width once there is. The request is updated wherever intent is actually expressed — a size prop change, the initial measurement, and the drag/keyboard handlers — so it restores the width the user dragged to, not just the coded size, which is the case this PR is really about.

Two tests, both confirmed failing against 40cfb8c before the fix:

✕ restores a numeric `size` when the referenceWidth grows back
  Expected: 800   Received: 540
✕ restores the user-dragged width, not `size`, when the referenceWidth grows back
  Expected: 700   Received: 540

Both now pass; full flyout suite is 464/464 and tsc/lint are clean.

Named sizes are unchanged — the proportional-scaling path is byte-identical to main, so this doesn't touch the behavior #9683 is about.

One pre-existing wrinkle I noticed while tracing this, not introduced here and left alone to keep scope tight: for named sizes the scale factor compounds off the clamped result, so if minWidth bites during a shrink, growing back can overshoot the original percentage (e.g. minWidth={300}, size="m", 1200 → 400 → 1200 lands at 900 rather than 600). Same shape of problem, different branch. Happy to file it separately if useful.

Ready for another look when you have a moment.

---

Generated by Claude Code

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: 17beead
• Documentation website
• Storybook
• ✅ Visual regression tests passed

History

• 💚 Build #5149 succeeded 40cfb8c
• 💚 Build #5148 succeeded 40cfb8c
• 💚 Build #5147 succeeded 4cf430f
• 💚 Build #5145 succeeded 4cf430f

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: 17beead

History

• 💚 Build #7745 succeeded 40cfb8c
• 💚 Build #7744 succeeded 4cf430f

[weronikaolejniczak]

blocking: Click / arrow while the flyout is clamped still fires onResize with the clamped width (and keyboard also overwrites requestedWidthRef). Discover persists that so the stored width is lost again.

Repro: size={800}, shrink container so it clamps to 540, click the handle (no drag) or press ArrowLeft at max → onResize(540). Grow the window back and keyboard path stays at 540; click path persists 540 for the next open.