Missing modifier release events on window focus change about kitty HOT 2 CLOSED

Yes, I haven't bothered to implement per window modifier state tracking.
What's the use case for this? Note that even with OS window focus
changes you cannot actually use modifier press/release events to track
modifier state reliably. Because glfw doesn't send synthetic press
events for depressed modifiers when an OS window gains focus. But it
does send synthetic release events. That these events are synthetic from
glfw is easily verified by running kitty with --debug-input.

Don't ask me why it works this way, but it does so on both X11 and
macOS. I am guessing it was some hack put in place a while ago for some
specific use case.

To me it would make more sense to not report the synthetic release
events on focus out at all. In general once focus out is allowed an
application simply cannot track modifier state, since anything could
happen to the modifier state while the application is unfocused and it
will have no way to know that. This applies for both graphical
applications and terminal applications using the keyboard protocol.

One would really need to implement some kind of modifier state update
event on focus in to do this reliably. But I am sceptical that this is
actually needed for a real world use case.

from kitty.

I am using modifier key events to control hover behaviours in my text editor (neurocyte/flow on github). I understand that it is unlikely to be perfect and I will have to use modifier bits from other events to detect unexpected modifier state changes.

That being said, I opened this issue mostly because of the difference in behaviour between kitty's internal windows switching and OS window switching.

• OS window switching sends a release event on focus change. This event zeros the modifier bits unconditionally.
• Kitty window switching there are no events on focus change and the effective modifier state in the application "sticks" until focus returns and some other event with modifier bits is sent.

At very least I'd like this to be consistent. Either leave the state as sticky in both cases or release in both cases. As it is now the modifier state may or may not stick depending on how the focus left the terminal, which is a little confusing.

An ideal solution, as you say, would be to have focus/unfocus events that also report the current modifier state and leave it up to the application to implement sticky or non-sticky behaviour. But I really think that should be a separate discussion. This is just about consistency for me.

from kitty.