Rework userEvent.type

We’ve got multiple open issues regarding the implementation of userEvent.type. And while a few people offered help on this, I’ve got the impression we’re a bit lost regarding what the code should do and look like in general as well as how and where each smaller problem should be addressed. I propose we collect those issues, discuss what we want to achieve and refactor and comment the code so that we get more confidence working on this.

• Typing on contenteditable #442
• Referencing characters by keyEvent.code #456
• Handling activeElement changing to another element #460 / #487
• Preserving input over value sanitization #479
• Typing on non-input elements #481 , #506
• Selecting on non-text input elements #501, #515
• Default behavior on clickable elements #554
• Prevent default behavior and missing events on navigation keys #578

Should I have overlooked something, please mention it and I’ll add it to the list.

What do people expect userEvent.type to do? What should it do? While userEvent.click is very clear and intuitive to use as userEvent click this element!, I guess userEvent.type started the same way userEvent trigger the key events to add to the value of this element!, but I think most people expect it to be more userEvent press those buttons on the keyboard!.

I think it should resolve around document.getSelection() and userEvent.type(null, "a{del}{shift}b{tab}c{/shift}[Semicolon]d{selectall}") should be a valid expression to test handling of hot keys and similar.

One problem that comes to my mind is how to handle the keypress events as they are triggered multiple times as long as the button is pressed. Maybe a configurable random timeout between key events? So that even an expression for Press [A] and then press [B] before releasing [A]. Then release [B]. would make sense.

[psullivan6]

I have found what I believe to be a related issue to this one, which is documented in this CodeSandbox: https://codesandbox.io/s/userevent-unit-test-ncmgu?file=/src/App.test.js

Setup of the tested component

1. contains a text input with an initial value of 1 string character (ex: '1')
2. executes the HTMLInputElement.select() method on input focus so every new value completely overwrites the previous one

Test execution:

1. Render the tested component with input
2. Get the input by role
3. Change the input value via userEvent.type(... (ex: '11123')
4. Notice the received input value is '23' and not '11123'

[sethreidnz]

I tend to agree with @nickmccurdy. Would it make sense to think about the different types of thing a user is actually trying to do and approach them differently with a different API. Specifically

• typing in an input (current type functionality)
• pressing buttons as commands / keyboard navigation

I feel like there is some core functionality in there perhaps but all the assumptions of clicking first and things like that, don’t make sense for someone pressing say shift + f to do a shortcut key in your app.