User-event: typing fails if input matches selection

[ph-fritsche]

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'

_Originally posted by @psullivan6 in https://github.com/testing-library/user-event/issues/521#issuecomment-796888618_

[ph-fritsche]

This is probably caused by fireInputEventIfNeeded. The key events fire as expected, the input event is missing.

[fergusmcdonald]

Hi @ph-fritsche 👋

What is reasoning behind not firing input events if newValue is the same as prevValue in fireInputEventIfNeeded? https://github.com/testing-library/user-event/blob/master/src/keyboard/shared/fireInputEventIfNeeded.ts#L27-L32

Is this a generalization which is mostly true for how the browser decides to fire input events? 🤔

I can see an input event is fired when replicating the issue in the sandbox.

https://user-images.githubusercontent.com/3115675/111896397-8efec500-89d6-11eb-8235-53a99aad78b1.mp4

Removing the rule will result in input events being fired in many scenarios where they shouldn't (see snapshots of commit referenced below).

[ph-fritsche]

@fergusmcdonald Thanks for taking the time to look into this. :smiley:

What is reasoning behind not firing input events if newValue is the same as prevValue in fireInputEventIfNeeded? https://github.com/testing-library/user-event/blob/master/src/keyboard/shared/fireInputEventIfNeeded.ts#L27-L32

Is this a generalization which is mostly true for how the browser decides to fire input events?

This is one of the parts of which I'm not sure yet, why they were implemented the way they are.

Removing the rule will result in input events being fired in many scenarios where they shouldn't (see snapshots of commit referenced below).

When rewriting the implementation for userEvent.type I tried to maintain the behavior that was established before, unless it was already determined to be a bug caused by the previous implementation of userEvent.type.
One of the reasons for the rewrite was that it should allow us to isolate concerns like the one tackled by fireInputEventIfNeeded and verify if the expectations laid out by the existing tests are correct.

https://codesandbox.io/s/keyevent-vtdcc?file=/src/App.js

[fergusmcdonald]

This is one of the parts of which I'm not sure yet, why they were implemented the way they are.

@ph-fritsche - This condition may have originated from the following spec: https://html.spec.whatwg.org/multipage/input.html#common-input-element-events

Examples of a user changing the element's value would include the user typing into a text control, pasting a new value into the control, or undoing an edit in that control. Some user interactions do not cause changes to the value, e.g., hitting the "delete" key in an empty text control, or replacing some text in the control with text from the clipboard that happens to be exactly the same text.

[ph-fritsche]

Yes, a misunderstanding of that paragraph might be the reason. There is no change event on blur if the value did not change.

[ph-fritsche]

There is no input event on <input type="number"/> though, if the added character leads to a value that can not result in a valid input by typing more characters. I.e. 1ee the second e is ignored.
But this should be addressed at https://github.com/testing-library/user-event/blob/74d191c0b1e9e113d8a27981fe422d2e623e3d2a/src/keyboard/plugins/character.ts#L109-L114

[ph-fritsche]

There is also no input event on <input type="date"/> for incomplete values.
The input events have no inputType or data.

[ph-fritsche]

@fergusmcdonald Thanks for starting the work on this. The main problem is solved now. But there are still a few edge cases that might need investigation.

[github-actions[bot]]

:tada: This issue has been resolved in version 13.0.14 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: