-
Notifications
You must be signed in to change notification settings - Fork 251
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
Support open shadow DOM components #1026
Comments
Could you add information how browsers handle selections, e.g. given a collapsed selection was placed outside the Shadow tree per |
It looks like this will require some research. For a correct implementation we need to know how the UI reacts to different interactions and which parts of the UI behavior are directly reflected by programmatically available properties/methods on the DOM. |
While a correct implementation should be the ultimate goal, for now I would be very happy with a working simple implementation. I do not know, but I think a selection over boundaries is not super common. |
How does the browser handle selections on shadow DOM? |
You are right. Well, I focused on the use case most common for us: inputs in an open shadow root. I wrote some basic tests. This should basically be enough for our use case at work as we are trying to test single components. Please if you find the time, let me know what you think: main...Christian24:user-event:main I didn't know what exactly you are aiming for, but if you like it, I will open a PR and it would probably allow us to adopt user-event in our current component tests. |
Problem description
Hello,
this is a follow up to #1025. Currently the library doesn't support web components which use shadow dom. This feature request only deals with open shadow doms. The underlying issue seems to be that with web components the element that is focused can be different from the one where input needs to take place: Web Components wrap builtin elements on which the input takes place. To get the element to interact with
document.activeElement
seems to be used. In case of web components this would return the web component, while the element that would need to be interacted with (e. g. an input element within the shadow DOM) is hidden from the library.Suggested solution
There has been prior art in the form of
getActiveElement
(https://github.com/testing-library/user-event/blob/main/src/utils/focus/getActiveElement.ts) which iterates over potential shadow DOM'sactiveElement
property, until the element to interact with is reached.This could be used as a replacement for
document.activeElement
to make the library open shadow DOM compatible. I quickly hacked this together onpaste()
and it seems to get the job done:https://github.com/Christian24/user-event/blob/f4242842c1ed51d2ec8042263bee7abdbafea21e/src/clipboard/paste.ts#L14
In some cases like keyboard input it seems to be more an issue of getting the element to focus properly first.
Interestingly,
user.click(element)
doesn't seem to focus the input within the web component, not sure why. I had to manuallyquerySelector
the input to get my paste test to work:https://github.com/Christian24/user-event/blob/main/tests/webcomponents/index.ts#L29
jsdom doesn't implement
delegatesFocus
currently: jsdom/jsdom#3418Additional context
I have been playing a little bit with this this afternoon: https://github.com/Christian24/user-event
Not sure it will evolve into a PR though, would like to hear seasoned contributors opinion first. Also for some reason I couldn't get the tests to debug in VS Code...
The text was updated successfully, but these errors were encountered: