-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add Shadow DOM support for useOverlay and improve event handling #7751
base: main
Are you sure you want to change the base?
Conversation
@snowystinger Anything I can do to get this one through ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your patience, we're in the midst of getting a release out.
@@ -101,7 +102,7 @@ export function useOverlay(props: AriaOverlayProps, ref: RefObject<Element | nul | |||
}; | |||
|
|||
let onInteractOutside = (e: PointerEvent) => { | |||
if (!shouldCloseOnInteractOutside || shouldCloseOnInteractOutside(e.target as Element)) { | |||
if (!shouldCloseOnInteractOutside || shouldCloseOnInteractOutside(getEventTarget(e))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that isChildOfActiveScope
might be problematic as well if the activescope is within a shadowroot
fireEvent.pointerUp(document.body); | ||
expect(isPrevented).toBeFalsy(); // meaning the event had preventDefault called | ||
}); | ||
}); | ||
}); | ||
|
||
describe('useOverlay with shadow dom', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Followup of #6046
This PR fixes an issue in
useOverlay
whereshouldCloseOnInteractOutside
always received the shadow root parent element as the argument whenever an element inside the shadow root was clicked.✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project:
Nutrient (formerly PSPDFKit)