Skip to content

fix: recover keyboard input when Chromium reports keyCode 229 with no IME active #335

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.

Sign up for GitHub

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

Open
drewvogg wants to merge 1 commit into
base: main
Choose a base branch
from
+25 −2
Open

fix: recover keyboard input when Chromium reports keyCode 229 with no IME active #335

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 25 additions & 2 deletions images/chromium-headful/client/src/utils/guacamole-keyboard.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1318,8 +1318,31 @@ Guacamole.Keyboard = function Keyboard(element) {

// Ignore (but do not prevent) the "composition" keycode sent by some
// browsers when an IME is in use (see: http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0182/keyCode-spec.html)
if (keydownEvent.keyCode === 229)
return;
//
// KERNEL: Some Windows + Chromium configurations report keyCode 229 for
// *every* keydown on a text field, even when no IME is in use (see:
// https://bugs.chromium.org/p/chromium/issues/detail?id=864911).
// Returning unconditionally here silently drops all keyboard input on
// those machines, while mouse input keeps working, because
// interpret_event() only interprets a log that begins with a keydown or
// a keyup -- the keypress that follows a dropped keydown is orphaned and
// never interpreted.
//
// Falling through recovers both known shapes of this quirk:
//
// - keyCode 229 with a usable "key" ("a", "Enter"): KeydownEvent
// already prefers "key" over "keyCode" when resolving a keysym.
// - keyCode 229 with key "Unidentified": the keydown resolves to a
// null keysym, and interpret_event() then takes the keysym from the
// following keypress, which carries the correct character.
//
// Only genuine composition is skipped. isComposing is false on the very
// first keydown that *starts* composition, so the "Process" sentinel is
// still needed to catch that event and avoid a duplicate keystroke.
if (keydownEvent.keyCode === 229) {
if (e.isComposing || keydownEvent.key === 'Process')
return;
}

// Log event
eventLog.push(keydownEvent);
Expand Down