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
reports an incorrect code on Linux for non-US keyboards when holding ctrl
down
#8116
Comments
Another report of this where Ctrl-UpArrow resolves to things like Ctrl-katakana at https://discuss.atom.io/t/ctrl-arrow-key-sends-unrelated-combination-to-atom/36405/5 |
Looks like this could be https://bugs.chromium.org/p/chromium/issues/detail?id=633838 and fixed in Chrome 56. If that is the same issue then the patch for it in https://codereview.chromium.org/2474083002 looks pretty small and probably could be applied against Electron's current Chrome version. @as-cii would you want this backported to 1.3.x or is Atom moving to 1.4 soon? |
I have a patch for this against Chrome 52 over at https://github.com/electron/libchromiumcontent/compare/control-dom-key-patch-52 With it applied against Electron 1.3.12 I can no longer reproduce the issue on Ubuntu 16.04. |
Awesome, @kevinsawicki. Thank you so much! Looking forward to seeing this shipped in Electron 1.3.13 and use it in Atom. 💯 |
Electron version: 1.3.9 (but it doesn't work properly on Chrome 54 either)
When receiving
keydown
events on Linux from a non-US keyboard layout, the.key
property will report an incorrect value if the user also presses Ctrl. In Atom, we have circumvented this issue by directly accessing the X11 APIs, but some users are experiencing problems on operating systems that have GNOME installed. This codepen illustrates the bug:i
.l
.Could this be fixed in Electron somehow? Alternatively, can the Electron team submit a patch to Chromium that solves this? Fixing it upstream feels easier than doing it in a library because we should have direct access to the operating system
KeyPress
events. Thoughts? 💭/cc: @groundwater @zcbenz
The text was updated successfully, but these errors were encountered: