Skip to content
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

Allow to pass an element to paste, copy, cut methods #1025

Closed
Christian24 opened this issue Aug 6, 2022 · 4 comments
Closed

Allow to pass an element to paste, copy, cut methods #1025

Christian24 opened this issue Aug 6, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@Christian24
Copy link

Problem description

Hello,

We want to use this library to write component tests for our web components. Since web components use builtin components within them (an input for example), the element that is currently focused might be different from the element we want to simulate user input on.

A simple example of this is a text field. A text field is web component with an input inside of it. If you will it just wraps the input element. So while the text field is focused, the user input is actually supposed to happen on the input. Sadly currently with Shadow DOM enabled there is no way to use paste, because it just uses document.activeElement:

const target = doc.activeElement ?? /* istanbul ignore next */ doc.body

Suggested solution

It would be great to have a utility API similar to type() to which you can just pass the element directly: https://testing-library.com/docs/user-event/utility/#type

This would give people using Shadow DOM a way to use this library.

Additional context

It looks like Shadow DOM support is still further away: testing-library/dom-testing-library#413

@Christian24 Christian24 added enhancement New feature or request needs assessment This needs to be looked at by a team member labels Aug 6, 2022
@ph-fritsche
Copy link
Member

Thanks for opening this issue.

We should aim to support Shadow DOM throughout all APIs. There are actually some lines in the internal utils to explicitly handle shadow hosts, but I think the considerations weren't properly documented (neither in the code nor in an issue or PR), so it's unclear which parts of the library already interact correctly with Shadow DOM and what would be necessary to add full support. (That is within the constraint to only handle open Shadom DOM, as providing workarounds for testing closed Shadow DOM would be another issue.)

The problem with any Utility API is that they introduce room for interpretation. Wherever possible we want to avoid this and provide APIs which describe a workflow that could manually be reproduced in a browser to provide a source of truth for the correct behavior.

Would you rewrite this or file a new issue that targets (open) Shadow DOM support in the existing APIs?
If you could research how focus and selection are handled in the browser and if there are other things to be considered, that would be a huge contribution towards this feature. 💚

@Christian24
Copy link
Author

Thanks for getting back to me. I opened a new issue: #1026

The problem with any Utility API is that they introduce room for interpretation. Wherever possible we want to avoid this and provide APIs which describe a workflow that could manually be reproduced in a browser to provide a source of truth for the correct behavior.

I understand your concern. However, I do not understand why this is okay for type() then. I don't want to argue about it, I just feel passing in the element directly gives a great deal of flexibility and control. And if it is allowed one place, it should possible everywhere.

@ph-fritsche
Copy link
Member

I understand your concern. However, I do not understand why this is okay for type() then.

I'm not sure we'd introduce .type() today. And if we did, I don't think we'd include initialSelection* or skip* options. Essentially making it a Convenience API i.e. just a shortcut for unambiguous low-level APIs.

passing in the element directly gives a great deal of flexibility and control.

It gives flexibility and control. But that's exactly the opposite of our goal: We try to provide APIs that let the author describe an interaction and lift the burden to make correct assumptions about what exactly happens on the perceived interaction.

@ph-fritsche
Copy link
Member

Closing in favor of #1026

@ph-fritsche ph-fritsche closed this as not planned Won't fix, can't repro, duplicate, stale Aug 16, 2022
@ph-fritsche ph-fritsche removed the needs assessment This needs to be looked at by a team member label Aug 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants