Might be a bit old:
https://developer.apple.com/documentation/uikit/uikeycommand/input_strings_for_special_keys -- Jeffry V. Herring Seacoast Laboratory Data Systems, Inc. From: Mike Jumper <mike.jum...@guac-dev.org> Reply-To: <user@guacamole.apache.org> Date: Monday, November 27, 2017 at 1:56 PM To: <user@guacamole.apache.org> Subject: Re: External keyboard with iPad On Sat, Nov 25, 2017 at 10:48 PM, Greg Trasuk <tras...@stratuscom.com> wrote: Hi Mike: Thanks for the reply. Here’s the result from the keypress tester: keydown e.keyCode=0 e.which=0 e.keyIdentifier=Unidentified e.key=UIKeyInputEscape e.altKey=false e.ctrlKey=false e.altGraphKey=false e.metaKey=false e.shiftKey=false e.location=0 e.keyLocation=0 keypress e.keyCode=85 e.which=85 e.keyIdentifier= e.key=UIKeyInputEscape e.altKey=false e.ctrlKey=false e.altGraphKey=false e.metaKey=false e.shiftKey=false e.location=0 e.keyLocation=0 keyup e.keyCode=0 e.which=0 e.keyIdentifier=Unidentified e.key=UIKeyInputEscape e.altKey=false So… looks kind of funny. The keycode reported is ’85’ which is the U character, but the key that’s reported is ‘UIKeyInputEscape’, which is clearly not ‘U’, and also not ESC (27). Googling ‘UIKeyInputEscape’ suggests that this is UIKit’s name for the escape key, but the keycode is wrong. It's unfortunately fairly common for at least one or two JavaScript key events and their properties to be completely incorrect. Guacamole's keyboard handling is actually one of the more complicated parts of the JavaScript side of the stack. We employ retrospective inspection of key events, looking over either or both of the keydown and keypress events depending on how reliable the associated properties are given other factors: https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L934-L938 In this case, iOS Safari shouldn't actually be sending a keypress event, as that event is supposed to only be sent for keys which would result in a printable character. It is this event which is resulting in Guacamole interpreting the key as a "U": https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L940-L944 Does Guacamole have some idea of an editable keymap? And if it did, would it be looking at the ‘key’ value or the ‘keycode’ value? The client side of things is meant to be independent of keyboard layout, so not exactly, but it does have a mapping of known key identifiers and known-accurate key codes (for the cases where a key code is always tied to a specific key). In those cases, it would ignore the keypress event and rely solely on keydown: https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L381-L506 https://github.com/apache/incubator-guacamole-client/blob/649fd8c036861014a6064f4af3e05f309cd92973/guacamole-common-js/src/main/webapp/modules/Keyboard.js#L174-L181 Though the "UIKeyInputEscape" identifier is non-standard, adding it to the above list would solve the issue. Do you perhaps know of where a full list of these UIKeyInput* names could be found? We could add them all in one fell swoop to fix this Safari quirk going forward. - Mike
