[EuiTreeView] Fix visible children overflow

[weronikaolejniczak]

Summary

max-height: 100vh on expanded nodes was intended to be combined with overflow: auto to form a self-contained scroll area. The Emotion migration (#7513) removed overflow: auto but left the max-height in place. It only limits the layout box, the content overflows and overlaps sibling items.

The solution is to explicitly override max-height to none when list item is "expanded". The children are conditionally rendered so there is no need for a CSS height restriction.

Why are we making this change?

It was raised on an internally-created bug issue: #9395

Screenshots #

Before	After
Kapture.2026-03-16.at.16.48.40.mp4	Kapture.2026-03-16.at.16.49.10.mp4

Impact to users

🟢 Doesn't remove the existing expanded class so it should not affect snapshots either. It's strictly a visual issue.

QA

Specific checklist

• Access the temporary testing story (locally or in staging and leverage DevTools)
• Verify that max-height: 100vh produces children that overlap sibling items
• Verify that max-height: none makes children take as much space as needed (if a scroll is needed on consumer side to limit how many children are displayed, it's better that they do it)
• Compare production and staging EuiTreeView Playground story and verify there's no regression

General checklist

• Browser QA
  • Checked in both light and dark modes
  • Checked in both MacOS and Windows high contrast modes
    • (emulate forced colors if you do not have access to a Windows machine.)
  • Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
  • Checked for accessibility including keyboard-only and screenreader modes
• Docs site QA
  • Added documentation
  • Props have proper autodocs (using @default if default values are missing) and playground toggles
  • Checked Code Sandbox works for any docs examples
• Code quality checklist
  • Added or updated jest and cypress tests
  • Updated visual regression tests
• Release checklist
  • A changelog entry exists and is marked appropriately
  • If applicable, added the breaking change issue label (and filled out the breaking change checklist)
  • If the changes unblock an issue in a different repo, smoke tested carefully (see Testing EUI features in Kibana ahead of time)
• Designer checklist
  • If applicable, file an issue to update EUI's Figma library with any corresponding UI changes. (This is an internal repo, if you are external to Elastic, ask a maintainer to submit this request)

[tkajtoch]

Everything works as expected 🚢

[Copilot]

Pull request overview

This PR fixes a layout bug in EuiTreeView where expanded nodes with many children were clipped to 100vh, causing later sibling items to overlap/interleave due to the max-height constraint without a corresponding overflow behavior (regression introduced during the Emotion migration).

Changes:

• Changed the expanded node styling to set max-height: none instead of 100vh, allowing expanded nodes to take the full height required by their (conditionally rendered) children.
• Added an upcoming changelog entry documenting the bug fix.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
packages/eui/src/components/tree_view/tree_view_item.styles.ts	Removes the 100vh max-height cap on expanded tree nodes to prevent sibling overlap.
packages/eui/changelogs/upcoming/9510.md	Records the EuiTreeView expanded-node clipping/overlap bug fix in the changelog.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: a9fb11b
• Documentation website
• Storybook

History

• 💚 Build #2990 succeeded 71bcae5

cc @weronikaolejniczak

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: a9fb11b

History

• 💚 Build #6062 succeeded 71bcae5

cc @weronikaolejniczak