chips: SPACE separator does not work with virtual keyboards on Android

[mina-skunk]

Bug, feature request, or proposal:

Bug

What is the expected behavior?

Separate chips on space when SPACE is set in MatChipInput.matChipInputSeparatorKeyCodes

What is the current behavior?

On Android devices it does not. (I personally tried Nesus X5 and pixel xl v1)

What are the steps to reproduce?

https://stackblitz.com/edit/chipinput
"android friendly chip input" uses keyup and looks at the last char of the input's value, to get around Android's "bad" keyboard event w/o keys and indistinguishable keycode 229.

What is the use-case or motivation for changing an existing behavior?

To be able to use MatChipInput on Android.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

All but on Android devices

Is there anything else we should know?

Android produces keycode 229 on space and other special characters.
Related to https://stackoverflow.com/questions/36753548/keycode-on-android-is-always-229/42552368

[rajatkhare619]

I'm also looking for a solution to this. Is there any workaround for using mat chips on Android?

[todd-skelton]

Same issue here for me.

[rajatkhare619]

For the time being, I modified the MatChipInput.prototype._emitChipEnd method on line 1739 in the file

\node_modules@angular\material\esm5\chips.es5.js

to emit the chipEnd event by manually checking the value of the input field.
This is just a temporary hack until we get a fix.

[jerome8]

Issue still occures in v7.3.6 :(

[josephperrott]

From looking into this a bit, it looks like this is caused by the fact that Android browsers always return 229 as the keycode regardless of what key is pressed.

One options for us would be to get the charCode of the previous character that was added, we would need affordances to ensure that we don't recheck the previous character twice in a row.

[josephperrott]

As I have continued to investigate here is a bit more information on the state of things.

• This only occurs with the virtual keyboard on Android devices, a hardwired USB keyboard produces the expected keyCodes.
• The getCharCodeAt() method on String returns the ASCII charCode which is different than the keyCode that is provided in keyboard events.
• The current recommendation (from mdn) for filtering events like this is actually to use key rather than keyCode, which returns the "result" of the keypress, i.e. shift + 1 produces event.key === '!' // true, while 1 produces event.key === '1' // true
• Currently we do our checks in the keydown event which means that the value of the input does not yet include the key that was pressed, so we would have to also look for the value in keypress or in keyup
• Based on this chromium bug it looks like this is something that is not likely to change, for many good reasons outlined in the bug.
• The value comes in as 229 because the keyboard that is bringing in the value is handling the processing of the strings coming in. (Basically because autocorrect is allowed, it goes into a composition mode)