You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A-InputPlayer input via keyboard, mouse, gamepad, and moreC-BugAn unexpected or incorrect behaviorO-LinuxSpecific to the Linux desktop operating system
ArchLinux with i3wm window manager alongside KDE using X11
What you did
I press Alt+Tab to change focus to my bevy application.
What went wrong
I expected this to change focus to my application, and nothing else.
What happend: It caused a key press event of the TAB key and triggered the application action associated with the TAB key.
This happens with any key that is used for focus switching. For example, if I use my window manager's "alt+w" key binding to switch to the workspace of the game, it registers as a key press of the "w" key, which causes my character to unintentionally move forward.
Worse yet, those keys get stuck in a "permanently pressed" state, triggering the actions forever, until I press the respective key once again.
This is driving me crazy as I switch focus back/forth between my bevy application a lot.
Additional information / Cause
This is caused by bevy erroneously interpreting winit's "synthetic" key presses as real key presses.
then the phantom key press events disappear in my application.
This is likely not the full solution though. While the phantom key press events are a clear bug, the phantom key release events might serve a purpose and possibly should be exposed. See rust-windowing/winit#3543 (comment)
If you decide to not filter out synthetic keys, please at least expose the fact that they are synthetic to the user so we can filter them out ourselves. This would be suboptimal solution, but better than nothing.
Relevant winit example: control_flow (or any other that responds to key presses)
A-InputPlayer input via keyboard, mouse, gamepad, and moreC-BugAn unexpected or incorrect behaviorO-LinuxSpecific to the Linux desktop operating system
Bevy version
0.13.2
Relevant system information
ArchLinux with i3wm window manager alongside KDE using X11
What you did
I press Alt+Tab to change focus to my bevy application.
What went wrong
I expected this to change focus to my application, and nothing else.
What happend: It caused a key press event of the TAB key and triggered the application action associated with the TAB key.
This happens with any key that is used for focus switching. For example, if I use my window manager's "alt+w" key binding to switch to the workspace of the game, it registers as a key press of the "w" key, which causes my character to unintentionally move forward.
Worse yet, those keys get stuck in a "permanently pressed" state, triggering the actions forever, until I press the respective key once again.
This is driving me crazy as I switch focus back/forth between my bevy application a lot.
Additional information / Cause
This is caused by bevy erroneously interpreting winit's "synthetic" key presses as real key presses.
If I add a check for is_synthetic in bevy's winit KeyboardInput event handler:
then the phantom key press events disappear in my application.
This is likely not the full solution though. While the phantom key press events are a clear bug, the phantom key release events might serve a purpose and possibly should be exposed. See rust-windowing/winit#3543 (comment)
If you decide to not filter out synthetic keys, please at least expose the fact that they are synthetic to the user so we can filter them out ourselves. This would be suboptimal solution, but better than nothing.
If I can help in any way with solving this, don't hesitate to ask.
Thank you.
P.S. here's an analogous fix in another UI framework: lapce/floem#387
The text was updated successfully, but these errors were encountered: