-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KeyboardEvent.key not working on certain Android devices #94
Labels
Comments
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While testing for issue #84 on Android I ran into an issue, whereby the KeyBoardEvent.key was producing undefined, causing issues with matching against delimiterChars. At the same time the default delimiters aren't useable on phone keyboard, due to lack of tab key and enter not being available, other than when suggested tags are shown.
When connected to a computer, for debugging the view in Chrome on the computer does provide event.key values on the phone, but not when typing from the phone's keyboard.
A limitation with
event.keyCode
, if we used that as fallback, is that 'A', 'a' and '@' all provide the same value, when using the US English layout.I tried using keyboardevent-key-polyfill, but that didn't prove of use since 'event.key' is technically supported, but not receiving the right values from the on-screen keyboard.
My initial tests were with an LG Stylo 2, running Android 7 and Chrome 60, though I did test with two other Android phones and got the same behaviour.
Note, that I did not experience any issue when testing with iOS.
Edit: Have opened a ticket against Chromium, to see if this could confirm a device bug or provide a lead to the issue cause:
https://bugs.chromium.org/p/chromium/issues/detail?id=763559
Update: per the response on the referenced ticket we should look into using
oninput
oronchange
instead, since the limitation encountered is apparently due to the behaviour of the 'soft keyboards'.Update: oninput won't provide us the values of non-printing characters. onchange only gives us the the new state. The ticket was marked as "Won't fix" which is a little disconcerting, since they have essentially broken
onKeyDown
when it comes to non-deprecated values.The text was updated successfully, but these errors were encountered: