Tree rendered inside Virtualizer from react-aria-components does not correctly virtualize when mounted inside a shadow root

[sdasneogi]

Provide a general summary of the issue here

Tree rendered inside Virtualizer from react-aria-components does not correctly virtualize when mounted inside a shadow root via ReactDOM.createRoot. The initial rendered range can be incorrect, and scrolling the tree container does not reliably update the rendered items.

This appears to be a regression in react-aria-components@1.17.0 / react-aria@3.48.0. The same reproduction works as expected in react-aria-components 1.16.x.

🤔 Expected Behavior?

A virtualized Tree inside a shadow root should behave the same as it does in the light DOM:

Initial render should start from the top of the tree.
Scrolling the tree container should update the virtualized item range.
Later items should render as the user scrolls.
Tree selection / expansion behavior should remain interactive.

😯 Current Behavior

When Tree is wrapped in Virtualizer and rendered inside a shadow root:

The rendered item range can be incorrect.
Scrolling the tree container does not reliably update the virtualized rows.
The scroll position changes, but the rendered items can remain stuck.
Non-virtualized tree behavior works, so the issue appears isolated to the virtualizer / scroll tracking path inside shadow DOM.

💁 Possible Solution

This was generated by LLM

root cause:
react-aria-components@1.17.0 introduced "Window scrolling in Virtualizer" and hardcoded allowsWindowScrolling: true in its private CollectionRoot component (the implementation behind the public Virtualizer export). This activates a fundamentally different visible-rect computation:

1.16.0 (working):

// Visible rect = just the scroll container's own position
new Rect(scrollLeft, scrollTop, clientWidth, clientHeight)
1.17.0 (broken):

// Visible rect = ancestor scroll offset + self scroll, clipped to window
new Rect(
viewportOffset.x + scrollPosition.x,
viewportOffset.y + scrollPosition.y,
Math.min(contentSize.width - viewportOffset.x, viewportSize.width),
Math.min(contentSize.height - viewportOffset.y, viewportSize.height) // ← clips items
)
viewportOffset is populated by a document.addEventListener('scroll', handler, true) ancestor-scroll listener. In Shadow DOM, this listener fires but nodeContains(target, ref.current) returns false (native Node.contains() can't cross shadow boundaries), so viewportOffset never updates — it stays at whatever getBoundingClientRect() returned at the initial mount position. The height formula then clips the visible rect to contentSize.height - mountY, shrinking the rendered window and leaving bottom items invisible.

The virtualizer appears to rely on scroll listeners / visible-rect calculation that are not correctly scoped to the shadow-root scroll container.

A possible fix would be to ensure virtualizer scroll handling works with shadow DOM by:

Listening directly on the virtualized scroll container, not only document.
Using shadow-DOM-aware event target handling.
Avoiding assumptions that scroll events or native event targets will behave the same after crossing a shadow boundary.
Ensuring visible rect calculation is based on the local scroll container when virtualizing inside a shadow root.

🔦 Context

We render components inside a shadow root for style isolation. After upgrading to react-aria-components@1.17.0, virtualized Tree behavior regressed inside shadow DOM.

This affects components that compose Tree + Virtualizer, including higher-level components that depend on virtualized tree/list rendering inside shadow-root portals or shadow-root app shells.

🖥️ Steps to Reproduce

https://codesandbox.io/p/devbox/funny-danny-nksfvn?workspaceId=ws_8Y7D6sLvDfpjduoiupTngc

Version

react-aria-components: 1.17.0 react-aria: 3.48.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

MacOS

🧢 Your Company/Team

athenahealth

🕷 Tracking Issue

No response

[slawton-athenahealth]

Hey Aria team! There's a small addendum from our investigation here that I'd like to add, but it's definitely a bit confusing. I created this StackBlitz on 1.17.0 that does show enableShadowDOM() working on a Tree as intended once the function is added back in (I linked it commented out to show that the problem reproduces): https://stackblitz.com/edit/82frcsa2?file=src%2FExample.tsx

It's not clear to me why this works using enableShadowDOM() and the example posted above doesn't. The way of adding the shadow root definitely differs from the other provided example, but that's because it is mimicking a place where we'd reproduced this issue in one of our internal applications, but the same "fix" of adding enableShadowDOM() doesn't work in that context. I'm including this example here because I hope it might help diagnose the bug in question; it works under some circumstances, but they seem niche (and can hopefully point towards a solution?)

[snowystinger]

After the update, can you confirm that you do not have multiple copies of any of our packages installed? I think that happened to someone else recently who said shadowdom stopped working for them. Second, are you importing the flag from the new sub path location? Or how are you importing it?

[sdasneogi]

Hi @snowystinger, we recently used the mono package codemod and updated all the libraries. We are using the enabledShadowDOM flag from the private path
import { enableShadowDOM } from 'react-stately/private/flags/flags';
just last week, we observed that clicks to checkboxes weren't happening in shadowDOM and that's when we updated some libraries and it worked for us but now we are seeing this issue too where Virtualizer isn't showing all the elements in shadowDOM
This was the issue that I raised - #10051

[snowystinger]

Looks fine in the stackblitz when I turn on the flag, nothing stands out at me that might be a misstep in your application. You'll need to either get it to reproduce in the stackblitz or start debugging. If it's easier, you could also try reproducing in our storybook and submit a PR with that story. Given that you're reporting this between the last two releases, you could try to narrow it down by bisecting with the nightly versions. You can read them like so:

https://www.npmjs.com/package/react-aria-components?activeTab=versions
3.0.0-nightly-092229c62-260518
This corresponds to 3.0.0 (arbitrary, ignore), nightly, 092229c commit on main, 260518 date YYMMDD

So if you can find a nightly just before it reproduces, then you're only looking at a couple PRs that went into main that could have caused it.

[slawton-athenahealth]

Hey again react-spectrum team! I have a series of StackBlitz environments that makes the issue here more consistent and clear, but I no longer think it's a regression since I think I can reproduce it in 1.16.0 as well:

• Non shadow DOM virtualization (for reference)
• Shadow DOM failing virtualization in 1.17.0
• Shadow DOM failing virtualization in 1.16.0 (note that I had to use ListBox here, but only because duplicating the code exactly was throwing an "Unknown list" error; I believe it demonstrates the same issue successfully).

We would love to get the shadowDOM working for this scenario in a future version, and I'll try to do a bit more digging to see if I can find a root cause. I suspect something like what the LLM described above, but it can't be that exactly since it calls out a 1.17.0 code change. Let us know if there's anything else we can help with, otherwise I'll reach back out if I find anything useful from further investigation!