Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keys leak through on window focus change (alt+tab) #3691

Closed
hut opened this issue May 9, 2024 · 2 comments
Closed

Keys leak through on window focus change (alt+tab) #3691

hut opened this issue May 9, 2024 · 2 comments
Labels
B - bug Dang, that shouldn't have happened DS - x11

Comments

@hut
Copy link

hut commented May 9, 2024

Description

General issue

Pressing window manager keys (such as alt+tab) outside the winit window which change focus to the winit window will cause winit to erroneously reports the key as being pressed.

For example, on X11, winit version 0.30.0, in the example "control_flow", when I press "Alt+r" (my window manager key to switch workspaces) to enter the workspace where the winit window is focused, the "Request Redraw" action of the example (bound to the "r" key) is unintentionally triggered.

This is contrary to any UI application out there: No other application will have any action triggered through my workspace switching keys. The only exception I can think of is one Unity Engine game.

Why am I bothered by this exactly?

I'm writing an application with the "bevy" framework which uses winit for key handling. Whenever I use window manager key bindings to change focus, I unintentionally trigger actions in the application. 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. Any pointers to a solution would be greatly appreciated. (I tried checking for whether the window is focused, this does not help.)

Thank you.

OS and window mananger

ArchLinux, i3 window manager on X11 alongside with KDE (no compositor).

Winit version

0.30.0

@hut hut added B - bug Dang, that shouldn't have happened DS - x11 labels May 9, 2024
@kchibisov
Copy link
Member

I'm pretty sure that the keys are synthetic: true, which means that you don't have to handle them and they are reported as a part of the keys being latched/released during the focus change.

You don't have to start any action from them and given that input on X11 is global there's nothing wrong with that.

@hut
Copy link
Author

hut commented May 9, 2024

Great lead! Thank you. This might well be it. Bevy doesn't filter out synthetic keys.

I will close this issue for now and investigate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B - bug Dang, that shouldn't have happened DS - x11
Development

No branches or pull requests

2 participants