feat: Add Shadow DOM support for useOverlay and improve event handling

[ritz078]

Followup of #6046

This PR fixes an issue in useOverlay where shouldCloseOnInteractOutside always received the shadow root parent element as the argument whenever an element inside the shadow root was clicked.

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

Nutrient (formerly PSPDFKit)

[ritz078]

@snowystinger Anything I can do to get this one through ?

[snowystinger]

Thanks for your patience, we're in the midst of getting a release out.

[snowystinger]

there are some 'relatedTarget' checks below, can we dive into a shadowDOM for those as well? i don't know if there is a composedPath for them

I could see this being an issue if getEventTarget is contained in e.relatedTarget or if the e.relatedTarget is a shadowroot and contains both targets that should be ignored as well as ones which shouldn't.
For example, if someone made a Toast Container inside a shadow dom, then clicking the toasts probably shouldn't count as outside but maybe clicking between individual toasts should for some reason.

[snowystinger]

that isChildOfActiveScope might be problematic as well if the activescope is within a shadowroot

[snowystinger]

I don't think these tests are going to be enough, usually overlays portal out to be a direct child of the body element, which would actually take them out of a shadowroot potentially

This can also be changed with UNSTABLE_PortalProvider

We'll need tests using the RAC Popover at a minimum

[snowystinger]

noticed that isElementInChildOfActiveScope calls node.contains in FocusScope

react-spectrum/packages/@react-aria/focus/src/FocusScope.tsx

Line 443 in 6a35a9a

return scope.some(node => node.contains(element));

Does this need to use the shadowDOM safe query we added in our utils?

What other tests might we need?

• the non-shadowDOM "firefox bug" describe needs to be checked either in an app or as a test in a shadowDOM environment
• If focus is moving into a child focus scope (e.g. menu inside a dialog)
• Can the underlay be outside the shadowDOM? what other setups might need coverage?
• shouldCloseOnInteractOutside={(target) => target !== underlay} what if we don't have access to underlay because the shadowroot is just the component instead of the entire app?

It may be easier to write some of these tests in the React Aria Component file

[snowystinger]

Is it weird that we call an external API with something that should be inside a shadowroot, it'd unintentionally leak shadow dom internals through our API

We don't do this in the pressEvents, though the use case is obviously a little different