WaitForSingleObject seems to receive a key release event without releasing the key

[iFuSiiOnzZ]

Windows Terminal version

1.14.1962.0

Windows build number

10.0.19043.1889

Other Software

C source to reproduce the bug.

Steps to reproduce

Use a C compiler as Visual CL. Build the source code posted "Other Software" section. Run the application build on Windows Terminal and press a key without releasing it, a key press and key release event is generated continuously.

Expected Behavior

Key press generates an event where "KeyEvent.bKeyDown" is true.
Key release generates an event where "KeyEvent.bKeyDown" is false.

Actual Behavior

When key is press an event is sent having the "KeyEvent.bKeyDown" to true, afterwards it generates a key release event, "KeyEvent.bKeyDown" to false, and it continuously generating key press and key release events without releasing the key.

In Command prompt and Powershell it works as expected.

[DHowett]

Thanks for the report!

So, this is one of those differences between the "terminal" model and the "console" model. When a key is input in a compliant terminal emulator (which Windows Terminal seeks to be), it is sent all at once: a. There's no distinction between the make and the break events.

Therefore, to keep up the illusion of terminal compliance: when we translate that input for the Windows Console API, we turn that single a into two simultaneous events: make a and break a.

Now, for a long string of input to a terminal emulator (aaaaaaaaaaaaa), it's a bit more nuanced. Terminal emulators are inherently generating input for a character device... so every bit of the input stream is processed character by character. That aaaaaaaa... becomes make a break a make a break a make a ... under the same translation scheme.

[DHowett]

It's a bit of a compatibility issue, admittedly. Unfortunately, it's the best we can do to keep our feet planted in both worlds (terminal emulation, plus the win32 console API).

[iFuSiiOnzZ]

Oh! Ok, is there any way to achieve the key press/release behavior? Hooking/Accessing "WindowProc" it would be a possibility?