Certain Key Up events are missed with combinations of keys

[BryceLTaylor]

Expected Behavior

Any key that triggers a key down event should trigger a key up event when it's released

Actual Behavior

Some key combinations will cause the key up to not trigger when released. This causes the reporter for <key [a] pressed> to report true after the keys are released.

Steps to Reproduce

On mac in any browser, pressing command-a will cause the a key to be pressed but releasing it does not release the a key. You can then press the a key briefly to stop it. It is easy to see if you build this stack (you can use any key to see the effects):

This works with any key. You can not get these results using ctrl on windows.

If you use [any] in the block, you can cause it to remain true after releasing keys by:
press and hold shift
press and hold the comma/left angle bracket key
release the shift key
release the comma/left angle bracket key

Operating System and Browser

Chrome, Safari, or Firefox on Mac. (tested on Windows Chrome and Edge. See the note about how the first example doesn't apply to using ctrl on windows)

[mzgoddard]

For the meta key on Mac, this is expected behaviour. There is no keyup events while meta is pressed (I think on windows the windows key is meta and not ctrl). So we can't detect exactly when the key was released in combination with meta.

There will be repeated keydown events until the key is released. We could use that to detect a key timeout but that'll generally be at least many 100s of milliseconds to many seconds after that last down event. (And we'd have to detect the timeout per system, since operating systems let you configure how often and when keys repeat.)

---

The comma and shift issue we can fix with a change to the keyboard data we depend on. GUI and VM currently use key member values from the KeyboardEvents. We could use or combine that with location or code values from the same events. key is the value of the event. While location and code are the physical key pressed. The comma key alone sends {key: ',', code: 'Comma'} with shift comma sends {key: '<', code: 'Comma'}. So following the sequence for the any key issue, the vm is receiving a < down event and a , up event. So the any key in that case is the < value.

This also happens with the alt key.

We might want to record the code of the key pressed for all down events, and then release all keys with the same code on up events.

[RokCoder]

Is there any movement on this bug? The shift key is particularly problematic on an emulator I'm working on. The user constantly finds keys typed with shift are auto-repeating if the key is released before the shift.

[RokCoder]

There's a fix for this by @GarboMuffin in TurboWarp -
TurboWarp@fbec54a and TurboWarp@9d69b93

[ArnoHue]

I ran into the same issue today (after users reported my Linux terminal project got stuck on certain input), namely shift-key release prior to main key release causing key-pressed to return true forever (even after project restart). Several Scratch forum postings reported that issue as well in the past. Backporting the TurboWarp bugfix would be highly appreciated.