The same issue fixed in this PR is also present in key combos with one or more modifier keys and multiple non-modifier keys (eg. cmd+i+j). In practice this means eg.

1. Press and hold cmd
2. Press and hold a
3. Press and hold b
4. Wait for over 2 seconds (>_kKeydownCancelDurationMac)
   Expected events: cmd down, a down, b down
   Actual events: cmd down, a down, b down, a up (synthesized)

This is a bit shame but at least I could not think of ways to work around this, any ideas are welcome. One option would be to delay the synthesizing of those non-modifier keys until the modifier is released (so the debouncing could be fully removed). But not sure if that would be any better as with that option too the framework might be out of sync for the non-modifier keys until the modifier is released.

Here's an idea:

Right now, we have a key guard for each physical, and we track repeat events for each physical key individually like you said. What if we make it a single key guard for all of the pressed keys. If any of the pressed keys is repeated, we keep restarting the single key guard. Do you think this could work?

That could work and would be slightly better than my original suggestion in this thread. In your suggestion releasing all other keys than the modifier key will synthesize the release of the non-modifier keys, whereas in my suggestion they'd be stuck as pressed until modifier is released. 🤔

However, both of the approaches have some drawbacks:

• The real state of keyboard might be out of sync with the state in the framework. In my suggestion all non-modifier keys could be released and the framework would think they're pressed until modifier is released. In your suggestion all but one non-modifier keys could be released and the framework would think they're pressed until the final non-modifier is released.
• The real release order is lost. We have no idea in which order the keys were actually released, so the synthesized events might (and most probably will) be fired in the wrong order. Not sure if we can do anything about this drawback as we're limited by the browsers events, which are pretty bad to begin with when modifier key is involved.

Should I open another issue for this sub-issue when the modifier keys are involved? I think we could still go forward with this PR as it fixes the issue perfectly when no modifier is involved (might already offer the necessary improvement for many game-devs). Whatever the solution for modifier key-combos will be, it will be a workaround. The browser already sends the key events perfectly when no modifier keys are involved, so we should handle those separately from the workaround (as we do in this PR).

In your suggestion all but one non-modifier keys could be released and the framework would think they're pressed until the final non-modifier is released.

Is this true?

Assume keys "R", "S" and "T" are pressed. The browser keeps sending repeat events for one of them, say "T".

When "R", for example, is released, the browser sends a "keyup" event, the engine will translate that to a ui.KeyEventType.up, the framework will know that "R" is no longer pressed.

I'm not sure why you say "the framework would think they're pressed until the final non-modifier is released". Could you clarify please?

Assume keys "R", "S" and "T" are pressed. The browser keeps sending repeat events for one of them, say "T".

When "R", for example, is released, the browser sends a "keyup" event, the engine will translate that to a ui.KeyEventType.up, the framework will know that "R" is no longer pressed.

Yes, this is true when no modifier key is involved. But its not true if one or more modifier is pressed.

How I got to this conclusion?

1. Print the key up and key down dom events

2. Press these keys in this order in the sample app

• cmd down
• j down
• k down
• j up
• k up
• cmd up

3. See the logs, only key up event logged is the one for cmd

With your suggested solution (if I understood it correctly) releasing the last non-modifier key will synthesize the key up event for all non-modifier keys. This means that as long as one or more non-modifier key is pressed, no key-up events will be synthesized (even if some keys are released) -> thus "the framework would think they're pressed until the final non-modifier is released".

Oh wow, that's weird. Looks like the behavior with Meta is different from other modifier keys. When Meta is pressed, the browser doesn't send keyup events for other keys.

We should make sure that the case of Meta + one key is handled correctly.

Other cases that involve Meta + multiple keys are impossible to handle 100% correctly. Any solution we pick is going to have downsides, and I don't have a strong opinion on which solution we should go with. I'll accept your PR as it's simpler than what I suggested earlier.

Implementation improvements

Oh, did some more debugging and that seems to be right, its only meta that behaves differently, not all modifiers. The changes in this PR were done under the assumption that its all modifiers. I'll modify the implementation to match with the results of this debugging. Good catch 🎣, don't know how I ended up thinking its all modifiers 😅

The meta limitations

  /// A limitation in this approach is that if meta key + multiple non-modifier keys are
  /// pressed at the same time, only the last pressed non-modifier key will send repeated
  /// events. This means that the guard will eventually synthesize keyup events for the other
  /// keys, even if they are still pressed.

Just to be clear, the changes in this PR don't yet do anything discussed in this thread for the meta + 2 or more non-modifier keys. The changes simply skip the key-up event debouncing if meta is not pressed, since in that case we can trust the events browser is sending. So with the changes in this PR, the same issue reported in the linked issue and documented in the comment in code still exist if meta-key is involved. So this will still happen, even though it probably should not:

1. cmd down
2. j down
3. k down
4. wait for 1500ms
5. j up is synthesized, even though its still pressed

Should I try to fix the meta-key too in this PR, or open a separate issue for it? I think separate issue might be good, since its impossible to handle 100% correctly -> might be worth asking around opinions on which of the ways to handle it is the least bad. The workaround for the meta-case anyways has to be kept separate from the changes in this PR (the non-meta case) as that we can handle 100% correctly by trusting the browser events.

I think this PR is good as is. It fixes the general issue with multiple key presses.

Pressing Meta + multiple keys while holding and releasing randomly is not a common pattern. Usually Meta is used for activating shortcuts, which typically involve pressing Meta + key 1 + key 2 then quickly releasing everything.

The issue of holding multiple keys and releasing some of them and then pressing others, sounds like a gaming thing. I imagine those keys usually don't include Meta.

I say let's merge this PR as is, and create a new issue for the Meta case with detailed explanation from this thread. We can fix it separately later. What do you think?

Sounds good, I'll open another issue! Thanks for the review 🎉