Fix #7064: Ignore key events without scan code #7145
Conversation
ghost
added
Area-Input
|
This seems reasonable to me, but I also don't really know if there are other kinds of inputs without scan codes. I guess I haven't seen it, but I'm also not usually looking for that. I'm not sure how we could be more pre-emptive about other input methods that we don't know, but we could make sure to add tests to cover this case, so that we don't regress it again in the future. Maybe something like just testing that |
|
I‘ll add a unit test as soon as I can. 🙂 |
|
I don't really see a usage of 0 scan code that would turn into something we could know how to handle without further user32 intervention. So I'm okay with this being "it's better than it was and if something proves us wrong, we'll refine further then." |
|
PR fixed. 👍 |
ghost
requested review from
|
Okay, let's scream test this! |
DHowett
added
the
AutoMerge
|
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
As always, thank you @lhecker! |
Up until #4999 we deferred all key events to the character event handler for which `ToUnicodeEx` returned a valid character and alternatively those who aren't a special key combination as listed in `TerminalInput`'s implementation. Since #4999 we started acknowledging/handling all key events no matter whether they're actually a known key combination. Given non-ASCII inputs the Win32 `SendInput()` method generates certain sequences that aren't recognizable combinations though and if they're handled by the key event handler no follow up character event is sent containing the unicode character. This PR adds another condition and defers all key events without scan code (i.e. those not representable by the current keyboard layout) to the character event handler. I'm absolutely not certain that this PR doesn't have a negative effect on other kinds of inputs. Is it common for key events to not contain a scan code? I personally haven't seen it happen before AutoHotKey/SendInput. Before this PR is merged it'd be nice to have a good testing plan in place in order to ensure nothing breaks. ## Validation Steps Performed Remapped `AltGr+8` to `»` using AutoHotKey using `<^>!8::SendInput {Raw}»`. Ensured `»` is printed if `AltGr+8` is pressed. Closes #7064 Closes #7120 (cherry picked from commit b617c43)
|
🎉 Handy links: |
…virtual keycode and a scan code of 0 (#15753) ## Summary Applications like PowerToys, with their keyboard remapping features frequently (i.e whenever a remapped shortcut is triggerred) send `KeyEvent` with out-of-range virtual keycode values (E.g. 0xFF). This is fixed for WT in #7145, we just needed it in our good ol' `conhost`. After this PR, Key events with an invalid virtual keycode and scancode==0 are ignored, and are not added to the `InputBuffer`. Incase, only virtual keycode is valid but not scancode, we will try to infer the correct scancode using the virtual keycode mapping. ## References and Relevant Issues #7145 #7064 ## Validation Steps Performed - Triggered a remapped shortcut and verified that `showkey -a` doesn't output `^@` unexpectedly. - Key events with an Invalid virtual Keycode and Scancode == 0 are ignored. - This PR doesn't include any changes for `WM_[SYS][DEAD]CHAR` messages, they are left unchanged.
Up until #4999 we deferred all key events to the character event handler
for which
ToUnicodeExreturned a valid character and alternativelythose who aren't a special key combination as listed in
TerminalInput's implementation.Since #4999 we started acknowledging/handling all key events no matter
whether they're actually a known key combination. Given non-ASCII inputs
the Win32
SendInput()method generates certain sequences that aren'trecognizable combinations though and if they're handled by the key event
handler no follow up character event is sent containing the unicode
character.
This PR adds another condition and defers all key events without scan
code (i.e. those not representable by the current keyboard layout) to
the character event handler.
I'm absolutely not certain that this PR doesn't have a negative effect
on other kinds of inputs.
Is it common for key events to not contain a scan code? I personally
haven't seen it happen before AutoHotKey/SendInput.
Before this PR is merged it'd be nice to have a good testing plan in
place in order to ensure nothing breaks.
Validation Steps Performed
Remapped
AltGr+8to»using AutoHotKey using<^>!8::SendInput {Raw}».Ensured
»is printed ifAltGr+8is pressed.Closes #7064
Closes #7120