fix(cdk/testing): account for preventDefault in keyboard events

[crisbeto]

Currently we try to mimic the user typing in the typeInElement utility by incrementally setting the value and dispatching the same sequence of events. The problem is that we weren't accounting for preventDefault which can block some keys from being assigned and some events from firing. This leads to inconsistencies between tests and the sequence of events triggered by a user. It is especially noticeable in components like the chip input where some keys act as separators.

These changes update the logic to take preventDefault into account and try to mimic the native event sequence as closely as possible.

Fixes #27475.

[crisbeto]

Note that I listed just the most common conflicting characters that may show up in a test string. Our approach for mapping characters to keycodes using charCodeAt(0) is fundamentally flawed for many more edge cases. It has been this way since we introduced test harnesses.

[andrewseguin]

Is there a better design we ought to use?

[crisbeto]

Ideally we would move away from using keyCode altogether, but there's a lot of code still depending on it.

The other option is to manually maintain a map of all characters to all key codes, but that'll only work for English letters and some keyboard layouts AFAIK.

I'm leaning more towards the first option but it'll take some effort.

[crisbeto]

Closing since the TGP revealed some fundamental issues with this approach and how we deal with key events in harnesses in general. We should revisit it once we've moved away from using KeyboardEvent.keyCode.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}