Redefine userEvent.clear behavior

[ph-fritsche]

Problem description:

The current implementation of userEvent.clear mixes user interactions with magic

userEvent.clear(element)

is only supported for input and textarea and currently translates to:

1. change the element.type to text if element isn't a textarea
2. click element with [MouseLeft]
3. and by that move selection to the end of the value
4. if the element supports selectionStart reset the selection to what it was before the click
5. mysteriously select the whole value without any user input ({selectall} input, not subject to event handling)
6. press [Delete] and remove value subject to event handling
7. change the element.type back to the original value

This is a mess of user input and magic which we certainly don't want to encourage.
And this behavior is not obvious to our users: #755

The specialChar {selectall} will be removed in user-event@14 as it is the only input for type/keyboard which does not describe a key stroke. This means there will a breaking change to userEvent.clear() anyway.

Suggested solution:

Either

1. Make clear a convenience wrapper for

   userEvent.click(element)
   // Could be {Delete} but {Backspace} usually is used on mobile
   userEvent.keyboard('{Control>}[KeyA]{/Control}{Backspace}')

   Which would make every step of it subject to event handling.
2. Set focus, then select all like the browser does on Ctrl+A, then delete content.
   Handle every step as if it was triggered by browser menu/screen reader - without any pointer/mouse/key events.

   FocusEvent
   SelectEvent
   InputEvent (inputType: deleteContentBackward)
   

3. Not recommended, just listed for completeness:
   Mysteriously set focus and select all children of the element which seems to be expected by our users but is not possible in UI.
   Then remove elements/text per one of the options above or just also mysteriously clear them from the DOM.

[ph-fritsche]

@kentcdodds Any opinion on this?

[kentcdodds]

I like this, but one challenge is this is inconsistent against all clients. On a Mac it's Cmd+A 😬 but maybe that's no big deal?

[ph-fritsche]

Good point.

Maybe this is a good argument for variant 2. If someone wants to simulate the keyboard/mouse events, they could still call those APIs directly.

Could you however record the events for that key combination on Mac? https://vtdcc.csb.app/
We might allow the users to define that per the keyboardMap if they want to.

[kentcdodds]

Sure! Here's what I got when I clicked into the input, pressed cmd+a, and then hit "delete" (which is the backspace button on regular keyboards but Apple likes to be special and calls it "delete" instead).

{"type":"pointerover","pointerId":1,"pointerType":"mouse","isPrimary":true,"x":68.10685729980469,"y":90.93473815917969}
{"type":"pointerenter","pointerId":1,"pointerType":"mouse","isPrimary":true,"x":68.10685729980469,"y":90.93473815917969}
{"type":"mouseover"}
{"type":"mouseenter"}
{"type":"pointerdown","pointerId":1,"pointerType":"mouse","isPrimary":true,"buttons":1,"x":112.19570922851562,"y":202.4324951171875}
{"type":"mousedown","detail":1,"buttons":1}
{"type":"focus"}
{"type":"pointerup","pointerId":1,"pointerType":"mouse","isPrimary":true,"x":112.19570922851562,"y":202.4324951171875}
{"type":"mouseup","detail":1}
{"type":"click","detail":1,"pointerId":1,"pointerType":"mouse"}
{"type":"keydown","key":"Meta","code":"MetaLeft","metaKey":true}
{"type":"keydown","key":"a","code":"KeyA","metaKey":true}
{"type":"select"}
{"type":"keyup","key":"Meta","code":"MetaLeft"}
{"type":"keydown","key":"Backspace","code":"Backspace"}
{"type":"input","inputType":"deleteContentBackward","value":""}
{"type":"keyup","key":"Backspace","code":"Backspace"}

[github-actions]

🎉 This issue has been resolved in version 14.0.0-alpha.10 🎉

The release is available on:

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

Your semantic-release bot 📦🚀