[jira] [Closed] (GUACAMOLE-2253) Shift key race condition causes mismatched keysym press/release pairs during fast typing

["Mike Jumper (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GUACAMOLE-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Jumper closed GUACAMOLE-2253.
----------------------------------

> Shift key race condition causes mismatched keysym press/release pairs during fast typing
> ----------------------------------------------------------------------------------------
>
>                 Key: GUACAMOLE-2253
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-2253
>             Project: Guacamole
>          Issue Type: Bug
>          Components: guacamole-common-js
>    Affects Versions: 1.5.5, 1.6.1 [staging]
>         Environment: Client OS: any (all major browsers — Chrome, Edge, Firefox, Safari)
> Target OS: any RDP/VNC/SSH target
>            Reporter: Adam
>            Priority: Major
>
> h3. Problem
> When typing rapidly, a user may release the Shift key before releasing the character key. The browser's {{keyup}} event for the character then resolves to the unshifted keysym because Shift is no longer held at the time of the {{{}keyup{}}}. This produces a mismatched keysym pair on the remote side — for example, {{keydown}} for {{A}} (0x41) followed by {{keyup}} for {{a}} (0x61).
> The server tracks key state by keysym. When the release keysym does not match the press keysym, the originally pressed key is never logically released on the server side. This can cause characters to appear stuck, subsequent input to behave unpredictably, or — in combination with lock-key state tracking — contribute to random capitalization artifacts.
> h3. Steps to Reproduce
>  # Connect to a Windows RDP target via Guacamole
>  # Open Notepad
>  # Type rapidly, briefly tapping Shift for individual capital letters then immediately continuing with lowercase (e.g., type "Hello World" at full speed, releasing Shift mid-keystroke)
>  # Observe occasional stuck shifted state or wrong characters, particularly when Shift is released between the keydown and keyup of a character key
> This is easier to reproduce with touch-typing at speed. The race window is small but consistent across all platforms and browsers.
> h3. Root Cause
> In {{{}Keyboard.js{}}}, the {{interpret_event}} function resolves the keysym for a {{keyup}} event using the current modifier state at the time the keyup is processed. If Shift was released before the character key, the keyup's modifier state no longer includes Shift, and the keysym resolves to the lowercase variant. The {{guac_keyboard.release()}} call then targets a keysym (e.g., 0x61 / {{{}a{}}}) that was never pressed — the original press was for 0x41 ({{{}A{}}}).
> h3. Proposed Fix
> Track non-modifier keys pressed while Shift is held in a {{shiftedKeys}} map, keyed by {{keyCode}} and storing the keysym used at press time. On Shift keyup (0xFFE1 or 0xFFE2), iterate the map and force-release each tracked key using its original (shifted) keysym via {{{}guac_keyboard.release(){}}}, then clear the map. On normal keyup of a tracked key, remove it from the map. On {{{}reset(){}}}, clear the map.
> This ensures the remote side always sees a balanced keysym pair regardless of the physical key release order.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)