Cant recognize KeyCodes, Codes and CharCodes from soft keyboards.

[alanllamas]

can't add tags with custom delimiters, every keycode returns 229, 0 or unassigned.

Most of all, it is a UX bug on mobile version because event keycodes doesn't match any character in mobile , so the only way to add a tag was addonBlur and you had to tap at the tag input again to submit another to the list.

It happens with android soft keyboards, was tested in browserstack and mobile devices on hand.

this issue is linked to issue #97

added some links as examples:
https://stackoverflow.com/questions/36753548/keycode-on-android-is-always-229
https://bugs.chromium.org/p/chromium/issues/detail?id=118639
https://social.msdn.microsoft.com/Forums/en-US/d9ac5d52-55f5-4e8f-b074-22323834a09c/keydown-event-always-returns-keycode-229?forum=vssmartdevicesvbcs

[i-like-robots]

Thank you for reporting this @alanllamas - it is an issue that has been discussed previously without conclusion. Unfortunately the "key mapping" step is not always performed on virtual keyboards (due to various processes running to compose text such as autocomplete) and so we get the unknown key codes. This behaviour can vary by device, keyboard used, and browser.

The only way to workaround for this that I am aware of is it compare the previous and current input value on the input event, however this adds significant complexity that I am unwilling to support and poses further questions such as how delimiters should be handled when copy and pasting and how it can call be reconciled when the allowNew option is enabled.

[alanllamas]

actually the only way i found to solve this is catching the last character typed by the user and match it to an object with keycodes.
In the case of pasting content i think it should be a nice approach checking every character being pasted and if a delimiter is found it creats a tag matching with existing tags, and even add it to the list when the allowNew option is enabled.
I made a pull request with a patch to solve the immediate problem, i could make it a full solution step by step if you consider it is a nice approach

[i-like-robots]

Unfortunately I fear there are a number of edge cases to consider and I think it will require complexity in order to get a consistent experience.

For example the key up event does not guarantee only one character changed, it will not always be triggered when using a swipe gesture to type, and the input may still be changed by autocorrect - either automatically or some time later by the user.

[i-like-robots]

And just to say - I really appreciate your efforts on this @alanllamas, it's a very complicated problem without easy answers!

[alanllamas]

i know!! it will be a sweet challenge, i broke my head figuring out how to patch it. Still im eager to find the solution my head is still scratching

[i-like-robots]

I've release 6.0.0-beta.3 which includes the solution implemented and tested in #181. I'm going to close this issue now as (hopefully) fixed.