fix(cdk/testing): account for preventDefault in keyboard events #27483
Conversation
crisbeto
added
P3
crisbeto
force-pushed
the
27475/fake-events-prevent-default
branch
3 times, most recently
from
ca57ddb
to
5b7fab9
Compare
crisbeto
force-pushed
the
27475/fake-events-prevent-default
branch
from
5b7fab9
to
6a500fb
Compare
| @@ -25,6 +35,15 @@ const incrementalInputTypes = new Set([ | |||
| /** Characters whose key code doesn't match their character code. */ | |||
| const KEYCODE_MISMATCHES: Record<string, number> = { | |||
| ',': COMMA, | |||
| '.': PERIOD, | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Is there a better design we ought to use?
There was a problem hiding this comment.
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
force-pushed
the
27475/fake-events-prevent-default
branch
from
6a500fb
to
4d37803
Compare
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 angular#27475.
crisbeto
force-pushed
the
27475/fake-events-prevent-default
branch
from
4d37803
to
41054b3
Compare
|
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 |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently we try to mimic the user typing in the
typeInElementutility by incrementally setting the value and dispatching the same sequence of events. The problem is that we weren't accounting forpreventDefaultwhich 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
preventDefaultinto account and try to mimic the native event sequence as closely as possible.Fixes #27475.