Skip to content

Phantom key presses on window focus change (alt+tab, etc) #13299

Closed
@hut

Description

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:

WindowEvent::KeyboardInput { ref event, is_synthetic, .. } => {
    if !is_synthetic {
        if event.state.is_pressed() {
            if let Some(char) = &event.text {
                let char = char.clone();
                app.send_event(ReceivedCharacter { window, char });
            }
        }
        app.send_event(converters::convert_keyboard_input(event, window));
    }
}

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

Metadata

Assignees

No one assigned

    Labels

    A-InputPlayer input via keyboard, mouse, gamepad, and moreC-BugAn unexpected or incorrect behaviorO-LinuxSpecific to the Linux desktop operating system

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions