userEvent.type(input, 'text') consistently shuffles the input

[jmyrland]

• @testing-library/user-event version: 12.0.11
• Testing Framework and version: jest@24.9.0
• DOM Environment: jsdom@14.0.0 (via jest-environment-jsdom-fourteen)

I'm having some issues with the following test-snippet (copied from the readme with some minor modification):

test('type', () => {
  render(<textarea />);

  userEvent.type(screen.getByRole('textbox'), 'hey');
  expect(screen.getByRole('textbox')).toHaveValue('hey');
});

When I run this, it fails with the following output:

Whatever text i input, it chucks the first input-character at the end, (i.e. 123 -> 231).

I'm guessing this is not the expected outcome - or if so, what am I missing? 😁

I'm using fireEvent.change(screen.getByRole('textbox'), { target: { value: 'hey' } }) as a workaround for now.

[kentcdodds]

I have reproduced this issue: https://codesandbox.io/s/pedantic-maxwell-wu50t?file=/src/__tests__/index.js

I'm guessing it's something odd with React because we absolutely have tests for this:

user-event/src/__tests__/type.js

Lines 109 to 144 in 26d2462

	test('types text in textarea', () => {
	const {element, getEventSnapshot} = setup('<textarea></textarea>')
	userEvent.type(element, 'Sup')
	expect(getEventSnapshot()).toMatchInlineSnapshot(`
	Events fired on: textarea[value="Sup"]
	textarea[value=""] - pointerover
	textarea[value=""] - pointerenter
	textarea[value=""] - mouseover: Left (0)
	textarea[value=""] - mouseenter: Left (0)
	textarea[value=""] - pointermove
	textarea[value=""] - mousemove: Left (0)
	textarea[value=""] - pointerdown
	textarea[value=""] - mousedown: Left (0)
	textarea[value=""] - focus
	textarea[value=""] - focusin
	textarea[value=""] - pointerup
	textarea[value=""] - mouseup: Left (0)
	textarea[value=""] - click: Left (0)
	textarea[value=""] - keydown: S (83)
	textarea[value=""] - keypress: S (83)
	textarea[value="S"] - input
	"{CURSOR}" -> "S{CURSOR}"
	textarea[value="S"] - keyup: S (83)
	textarea[value="S"] - keydown: u (117)
	textarea[value="S"] - keypress: u (117)
	textarea[value="Su"] - input
	"S{CURSOR}" -> "Su{CURSOR}"
	textarea[value="Su"] - keyup: u (117)
	textarea[value="Su"] - keydown: p (112)
	textarea[value="Su"] - keypress: p (112)
	textarea[value="Sup"] - input
	"Su{CURSOR}" -> "Sup{CURSOR}"
	textarea[value="Sup"] - keyup: p (112)
	`)
	})

I'm not sure what the problem is, but if someone wants to investigate and figure out what we're doing wrong that would be great.

[jmyrland]

I just noticed this:

@testing-library/user-event@12.0.11" has unmet peer dependency "@testing-library/dom@>=7.16.0".

Might this be related?

[lourenci]

I can take a look at this later.

[nickserv]

Notes

1. The original sandbox depends on Jest DOM, doesn't have peer dependency warnings for it, and still fails
2. This is still an issue in 12.0.11
3. This is not an issue if you swap out the textarea with an input
4. This is still an issue without React

[nickserv]

This bug was introduced in #322 (version 11.3.1)

[marcosvega91]

this issue is like #346. The problem is that when the textarea has no default value both selectionStart and selectionEnd are undefined. I have tried locally in the past but this issue not happens. It happens only in codesandbox.

We can add a check at the beginning of type function, but it's very odd
working example

diff --git a/src/type.js b/src/type.js
index 0bee11e..632dc97 100644
--- a/src/type.js
+++ b/src/type.js
@@ -65,6 +65,15 @@ async function typeImpl(
     }
     return value
   }
+
+  if (
+    typeof currentElement().selectionStart === 'undefined' ||
+    typeof currentElement().selectionEnd === 'undefined'
+  ) {
+    currentElement().setSelectionRange(0, 0)
+  }
+
   const setSelectionRange = ({newValue, newSelectionStart}) => {
     // if we *can* change the selection start, then we will if the new value
     // is the same as the current value (so it wasn't programatically changed

[kentcdodds]

Is there any way we can alter the code in other places so we don't actually set the selection range?

[nickserv]

Unfortunately I think it'll be hard to test this out until we can reproduce it locally. As far as I'm aware this bug only reproduces on Code Sandbox, but I don't think it supports linking packages.

Should we file this and #346 (which appears to still be an issue) upstream in JSDOM instead?