When translating clipboard to numpad events, use the *input* CP#19511
Merged
When translating clipboard to numpad events, use the *input* CP#19511
Conversation
I looked as far back as I was able to find, and we've used the OutputCP since at least Windows NT 3.51. I think it has _never_ been correct. At issue today is the GB18030-2022 test string, which contains the following problematic characters: * `ˊ` `U+02CA` Modifier Letter Acute Accent * `ˋ` `U+02CB` Modifier Letter Grave Accent * `˙` `U+02D9` Dot Above * `–` `U+2013` En Dash They cannot be pasted into PowerShell 5.1 (PSReadline). It turns out that when we try to synthesize an input event (Alt down, numpad press, Alt up **with wchar**) we are using their output codepage 65001. These characters, of course, do not have a single byte encoding in that codepage... and so we do not generate the numpad portion of the synthesized event, only the alt down and up parts! This is totally fine. **However**, there is also a .NET Framework bug (which was only fixed after they released .NET Core, and rebranded, and the community stepped in, ...) finally fixed in .NET 9 which used to result in some Alt KeyUp events being dropped from the queue entirely. dotnet/runtime#102425 Using the input codepage ensures the right events get synthesized. Technically, padding them with numpad input events is _also more correct_. It also scares me, because it has been this way since NT 3.51 or earlier.
Member
|
|
zadjii-msft
approved these changes
Oct 30, 2025
DHowett
added a commit
that referenced
this pull request
Feb 11, 2026
We do not have good test coverage for the `WindowsInbox` build. - ClipboardTest regressed with #19511 - DECRQCRA tests were not written for WindowsInbox - FTCS marks tests were not written for WindowsInbox
DHowett
added a commit
that referenced
this pull request
Feb 11, 2026
We do not have good test coverage for the `WindowsInbox` build. - ClipboardTest regressed with #19511 - DECRQCRA tests were not written for WindowsInbox - FTCS marks tests were not written for WindowsInbox After this PR: Summary: Total=7182, Passed=7160, Failed=3, Blocked=0, Not Run=0, Skipped=19 The 3 failing tests are in the integrity level FT, and they fail because they expect to be run in an empty console window (the test reads buffer output starting from 0, 0.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I looked as far back as I was able to find, and we've used the OutputCP since at least Windows NT 3.51.
I think it has never been correct.
At issue today is the GB18030-2022 test string, which contains the following problematic characters:
ˊU+02CAModifier Letter Acute AccentˋU+02CBModifier Letter Grave Accent˙U+02D9Dot Above–U+2013En DashThey cannot be pasted into PowerShell 5.1 (PSReadline).
It turns out that when we try to synthesize an input event (Alt down, numpad press, Alt up with wchar) we are using their output codepage
65001. These characters, of course, do not have a single byte encoding in that codepage... and so we do not generate the numpad portion of the synthesized event, only the alt down and up parts!
This is totally fine. However, there is also a .NET Framework bug (which was only fixed after they released .NET Core, and rebranded, and the community stepped in, ...) finally fixed in .NET 9 which used to result in some Alt KeyUp events being dropped from the queue entirely.
dotnet/runtime#102425
Using the input codepage ensures the right events get synthesized. It works around the .NET bug.
Technically, padding in those numpad input events is also more correct.
It also scares me, because it has been this way since NT 3.51 or earlier.