Remove synthetic key events?

[madsmtm]

Raised in #3538 (comment).

Should we remove synthetic keyboard events (those that contain is_synthetic)?

What are the benefits and the drawbacks?

[kchibisov]

I'd rather move them out of normal events, because folks handle them but these events shouldn't trigger general input.

[dhardy]

Synthetic press events: I don't have a use for them.

Synthetic release events (i.e. matching a real press): these are useful to notify that a press-and-hold sequence should be terminated.

[kchibisov]

Yeah, but you generally should assume that every key is lifted upon focus lost, since that's mostly the only case where it can happen iirc. But yeah, releases make more sense than presses, since people may think that they should input from synthetic presses, while in really it's not the case.

[dhardy]

Sure, I could handle the key-releases on my end.

I guess the only real thing is whether keys held while the window does not have focus are handled correctly.

I can trick my text editor like this, but it's unimportant: focus another window, press and hold Alt, click to focus the editor, press F. The File menu is opened but the access keys are not underlined like usual.

More important might be something like Blender where modifier keys affect what click+drag does. But to handle that correctly the synthetic key press has to arrive before the mouse-click event, and that's still not good enough to handle cursors (in case the modifier key should change the mouse cursor seen on hover).

It is also possible to handle this stuff without synthetic key presses; they just make that easier (assuming they do the right thing).

[kchibisov]

You shouldn't handle represses when you had something latched upon focus though, the general recommendation to never do so, because it's always not intended. That's the general advice by core wayland protocol as well and the same with x11, I think.

I can trick my text editor like this, but it's unimportant: focus another window, press and hold Alt, click to focus the editor, press F. The File menu is opened but the access keys are not underlined like usual.

You generally shouldn't replay button presses, because user could use this modifier as a part of e.g. Alt+Tab so you end up releasing and showing the menu on focus from such switcher, this is most of the time not desired from the UX point of view, because user haven't asked for that.

It is also possible to handle this stuff without synthetic key presses; they just make that easier (assuming they do the right thing).

ModifiersChanged is not synthetic and always broadcasted to you and rebroadcasted on focus change, so if you want e.g. shift+mouse drag it should just work, with the exception of unfocused clients where the modifiers are considered empty now, though it'll likely change. Keep in mind that some Wayland compositors don't send modifiers when the application is not focused even when you have mouse pointer above it, though wayland-core allows that. We have #2768 for that and it'll be addressed.

[hut]

For reference, here is an incomplete list of UI frameworks that mistakenly interpret synthetic key presses as real key presses:

• https://github.com/emilk/egui
• https://github.com/slint-ui/slint with SLINT_BACKEND=winit
• https://github.com/bevyengine/bevy (ongoing issue: Phantom key presses on window focus change (alt+tab, etc) bevyengine/bevy#13299)
• https://github.com/lapce/floem (fixed since fix: ignore synthetic keyboard input lapce/floem#387)
• https://github.com/iced-rs/iced

I'm guessing every UI framework will make this mistake, until, after years of subtle customer confusion/annoyance, they realize what is going on and fix the bug on their end.

Perhaps it would be best to hide the synthetic key press events by default.