Pressing the number keys no longer works for traversing it (except 0). Pressing some keys such as space and esc traverse through it now.
Comments 5
I can also confirm, I’m getting the exact behavior described. I have tried to change my keyboard layout, use the numpad with and without numlock, but nothing works. Going back to an older version fixes it immediately.
Can confirm.
And, besides the keys already mentioned, I was also able to reproduce the behavior with the following shortcuts using an English (US) keyboard layout:
Ctrl + Backspace
Ctrl + Tab
Ctrl + Shift + Tab
Ctrl + 0
Ctrl + -
Ctrl + =
Ctrl + [
Ctrl + ]
These shortcuts incorrectly interact with the tab navigation in affected screens instead of performing their normal behavior.
I investigated this further and found that the incorrect mappings are not random. They appear to be caused by the migration from GLFW key tokens to SDL3 scancodes in Snapshot 4.
Before the migration, InputWithModifiers.input() used GLFW key tokens, where the digit keys (GLFW_KEY_0–GLFW_KEY_9) are consecutive values. This made it valid to derive the digit by subtracting the value of GLFW_KEY_0.
After the migration, InputWithModifiers.input() uses SDL3 scancodes, which represent physical key positions instead. Since SDL orders the number row as SDL_SCANCODE_1–SDL_SCANCODE_9, followed by SDL_SCANCODE_0, the same approach no longer works and the subsequent scancodes are interpreted as digits, matching the observed behavior:
I accidentally posted my previous comment before I had finished writing it. Continuing here:
0 works as digit 0
Enter behaves as 1
Escape behaves as 2
Backspace behaves as 3
Tab behaves as 4
Space behaves as 5
- behaves as 6
= behaves as 7
[ behaves as 8
] behaves as 9
This can be verified from the official documentation:
GLFW key tokens: https://www.glfw.org/docs/latest/group__keys.html
SDL3 scancodes: https://wiki.libsdl.org/SDL3/SDL_Scancode
Can confirm.