Bugs in Console
members KeyAvailable
and ReadKey()
on Windows platform
#102425
Labels
Console
members KeyAvailable
and ReadKey()
on Windows platform
#102425
General
The
public static System.Console
API mostly redirects to the platform-specific implementations ininternal static System.ConsolePal
. For Windows, that's in ConsolePal.Windows.cs, so I will refer to the latter directly.runtime/src/libraries/System.Console/src/System/ConsolePal.Windows.cs
Line 284 in 5474ab5
runtime/src/libraries/System.Console/src/System/ConsolePal.Windows.cs
Line 323 in 5474ab5
Bug 1: Inconsistent logic between
KeyAvailable
andReadKey()
The code peeking at the input queue in
KeyAvailable
uses a different logic than the code reading the input queue inReadKey()
. As a result, when invokingKeyAvailable
,An unicode char synthesized via a
Alt
key-up event will be silently eaten and is no longer available to a subsequentReadKey()
call. OTOH,ReadKey()
without previousKeyAvailable
will read that char correctly.This affects input via an
Alt
plusnumpad number
sequence, pasted chars without key equivalent, and problably IME-generated chars as well.A keydown event in the input queue for any combination of
Alt
withnumpad number
keys,arrow
keys,page up/down
keys,Home/End
keys, and theInsert
key will returntrue
, signaling that a subsequent call toReadKey()
should return that key and should not block.Unfortunately, the opposite happens, because
ReadKey()
silently eats these keys in anticipation of a subsequent synthesized key (which will only happen for some of these, see below). As a result, a call toReadKey()
will block and not return, despiteKeyAvailable
having signaled otherwise.Bug 2:
ReadKey()
incorrectly skips valid keydown eventsThis is again related to synthesized unicode chars from an
Alt
plusnumpad number
input sequence, which are surfaced via a subsequentAlt
key-up event.The code correctly skips such keydown events for virtual
numpad number
keys. Each of the corresponding physical keys has a second virtual key that gets sent whenNumLock
is off, soReadKey()
skips them as well, because synthesizing happens regardless of the NumLock state.However, on most keyboards, those keys exist twice - once on the numpad, and once on the arrow pad and control pad. Only the keys on the numpad will produce a synthesized unicode char, but
ReadKey()
lumps them together causing the keys on the control and arrow pad to be silently eaten.Proposed fix
main...mawosoft:runtime:fix-consolepal-windows
I can submit a PR if that's desirable.
The text was updated successfully, but these errors were encountered: