guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Jumper <mike.jum...@guac-dev.org>
Subject Re: External keyboard with iPad
Date Mon, 27 Nov 2017 18:56:57 GMT
On Sat, Nov 25, 2017 at 10:48 PM, Greg Trasuk <trasukg@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

Mime
View raw message