Left shift sometimes gets stuck reporting as being pressed down, even when released

[20k]

Tested versions

v4.7.2.stable.official [ed1daf0], and 4.7.2 RC1

System information

Godot v4.7.2.stable - Windows 10 (build 19045) - Multi-window, 2 monitors - Direct3D 12 (Forward+) - dedicated AMD Radeon RX 6700 XT (Advanced Micro Devices, Inc.; 32.0.21045.1000) - AMD Ryzen 7 5800X 8-Core Processor (16 threads) - 31.92 GiB memory - WASAPI (48000 Hz, Stereo/mono)

Issue description

I solemnly swear that this bug is real, its just hard to reproduce

Sometimes, when hitting left shift, the key gets stuck on. Ie, Input.is_action_pressed("zoom") (left shift) inappropriately reports true after the key is released. I've checked that this is not my keyboard, and multiple playtesters were able to reproduce this in a real project on their own machines. It only seems to affect left shift

I've been able to find out a few things:

1. It is more likely to reproduce when other events are happening, moving the mouse around is usually enough to trigger it after a dozen or so attempts, sometimes in combination with the scrollwheel
2. Its much more likely to reproduce if you hold shift down for long enough to trigger echo events, simply spamming left shift won't reproduce it
3. GetAsyncKeyState(VK_SHIFT) returns the correct key state
4. Capping the FPS may be important to triggering it, but this is probably incidental
5. Godot reports an extra unwanted pressed event, immediately after the last released event (when releasing the key), and it is reported as being an echo
6. Disabling input accumulation does not fix it

If I had to guess, there's a race condition which can result in an extra echo event being processed after the last release event, causing the key to get stuck on

Thanks!

Steps to reproduce

1. Hit left shift until you see at least one echo event while continuously wiggling the mouse, and potentially scrolling the mouse cursor - then release it
2. Notice that eventually, an extra Shift Pressed true command is sent after Shift Released, as the shift key is released

Uncommenting the line:

#print(Input.is_action_pressed("zoom")) #useful to show the issue

Also shows that this isn't simply a misfiring event pair, and it causes the input action system to report the wrong result, as this inappropriately returns true

Minimal reproduction project (MRP)

bug-lshift.zip

[Calinou]

• Related to Fix performance issues when moving the mouse with high polling rate on Windows #109639 (since it only happens when moving the mouse).

I can confirm this on 4.8.dev3 (Windows 11 24H2, 240 Hz display, 1000 Hz mouse polling rate). On average, it occurs after 3-4 attempts:

gh_122554.mp4

I couldn't reproduce this on 4.7.1.stable, which doesn't include #109639.

Edit: I bisected the regression to #109639.

cc @bruvzg @vorvek

[vorvek]

My hypothesis is that #109639 moved raw-input draining ahead of the normal Windows message pump. A raw Shift-up can thus be converted into a release event before older queued WM_KEYDOWN repeated messages are dispatched, producing this sequence: release, echoed press. Mouse traffic makes that backlog/order inversion easier to happen.