Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

typing fails if input matches selection

See original GitHub issue

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

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

Test execution:

Render the tested component with input
Get the input by role
Change the input value via userEvent.type(... (ex: '11123')
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_

Issue Analytics

State:
Created 3 years ago
Comments:9 (8 by maintainers)

Top GitHub Comments

1reaction

github-actions[bot]commented, Mar 25, 2021

🎉 This issue has been resolved in version 13.0.14 🎉

The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot 📦🚀

1reaction

ph-fritschecommented, Mar 21, 2021

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

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