Tracking Issue: Sync key press/release with window focus

[goddessfreya]

• Implemented on all platforms
  • Windows - Implement windows focus key press/release on Windows  #1307
  • macOS (Tracking Issue: Sync key press/release with window focus #1272 (comment))
  • iOS
  • Linux X11 - X11: Sync key press/release with window focus #1296
  • Linux Wayland
  • Web

As mentioned in #1262 (review), however over the window, hold any key, move off the window release the key. You won't get the released key event. Ever.

https://gist.github.com/goddessfreya/39ae1f768cde5bdbc8c9aefa25984824
https://gist.github.com/goddessfreya/0192aa8d9920dba7c933c98190c42d90

cc @murarth

Related: #1077

[Osspial]

This is a problem on Windows as well. I wouldn't be surprised if we had this issue everywhere.

IMO the simplest solution is to automatically send a KeyUp event for all pressed keys whenever the active window loses focus.

[murarth]

Is this really an issue winit needs to solve? I feel like applications should be expected to handle this, if appropriate, by responding to Focused events. If we start generating artificial key release events, there's no way to opt out of it.

[OvermindDL1]

It could be opt in perhaps, by setting a flag or so, or opt-out?

[Rua]

Automatically sending KeyUp events just shifts the problem back to KeyDown events. What if the window loses focus, the user releases the key, and then presses it again before refocusing the window? Then you have a KeyUp event without a preceding KeyDown event.

[goddessfreya]

@Rua IMO, when a window loses focus, we should send a KeyUp for all keys currently held down. When the window regains focus, all keys currently held down should send a KeyDown. I'm not sure how feasible this is on other platforms, but it should be achievable on X11. This should make it so that every KeyUp has a matching KeyDown and vice versa.

@murarth If we are expecting users to listen to the Focused events and track the keys via DeviceEvent::Key, then what use is WidnowEvent::KeyboardInput?

[murarth]

@goddessfreya I'm not suggesting that application developers should use DeviceEvent::Key for all key press responses. I just think that, if an application's behavior is sensitive to focus loss while a key is held, it may be better handled by the application than by winit generating artificial events. I just feel that, if we go down the road of generating artificial events, we may encounter unforeseen complications.

On the other hand, I can't really think of a use case where an application would want the current behavior. And if there's only one "correct" way for applications to workaround this issue, it would make sense for winit to exhibit that behavior itself.

Anyway, if the consensus is in favor of fixing this, I concede the point and will implement this for X11.

[goddessfreya]

@murarth I also can't think of a use case for the current behavior. If some applications don't want these artificial events and wish to maintain existing functionality, I think they should use DeviceEvent::Key and just ignore them when focus is gone.

I'm honestly not sure which applications would want the existing behavior, tho. I think most people assume, or at least I did, that when a window looses focus all the keys held will be released, and vice versa for when focus is regained. At the bare minimum, I imagine most people believe that for every key up they should receive a key down, and for every key down there will be a key up (if the user releases the key).

I'm not sure what complications might result from us injecting the occasional key up/down here and there, but if that's a concern, we can mark some WindowEvents as "artificial" with a bool and users can just filter them out.

EDIT: As an alternative implementation, when a window regains focus, we could just issue all the necessary key ups/downs. This strikes me as slightly harder to implement on winit's side and less useful than my other proposed solution.

[OvermindDL1]

At the bare minimum, I imagine most people believe that for every key up they should receive a key down, and for every key down there will be a key up (if the user releases the key).

Oh this is a big falsehood right there.

Let's take key repeat, like holding a, you'll get a lot of keydown's but only a single key up (if even then).

[goddessfreya]

At the bare minimum, I imagine most people believe that for every key up they should receive a key down, and for every key down there will be a key up (if the user releases the key).

Oh this is a big falsehood right there.

Let's take key repeat, like holding a, you'll get a lot of keydown's but only a single key up (if even then).

@OvermindDL1 Maybe I was not being clear, but this is consistent with what I said. If they held down a, there is still a key up for the key downs if the key is released. And the key up will have at least one key down before it.

[OvermindDL1]

And the key up will have at least one key down before it.

Eh, that's not always the case either. The events from the hardware don't work that way, and thus neither do any window manager I've seen as well, there are always unexpected things. I personally do not want magical keydowns to be sent if focus is lost, I can handle that if I so wish, and in some cases I do, and in some cases I don't. I don't want fake input events. Opt-in maybe, but not opt-out. It should match the expected OS events by default, no fake events by default.