Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sending unicode character via KEYEVENTF_UNICODE/VK_PACKET in SendInput outputs the wrong characters #12977

Closed
jtroo opened this issue Apr 25, 2022 · 5 comments · Fixed by #13667
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@jtroo
Copy link

jtroo commented Apr 25, 2022

Windows Terminal version

1.12.10982.0

Windows build number

10.0.19043

Other Software

Reproducible in:

  • cmd.exe
  • wsl ubuntu 20.04

powershell just displays ?? , not sure which behaviour is more incorrect

Uses SendInput:
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendinput

Steps to reproduce

Via SendInput, send the unicode character 🙁

E.g. in
https://github.com/jtroo/kanata/blob/master/src/oskbd/windows.rs#L168

Expected Behavior

The correct unicode value gets typed in: 🙁

Actual Behavior

The characters 翿翿 are typed in instead

Additional info

When copy-pasting the unicode character, it's rendered correctly (in cmd/wsl). It's just not typed correctly via SendInput.

@jtroo jtroo added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Apr 25, 2022
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Apr 25, 2022
@jtroo jtroo changed the title Sending unicode character via KEYEVENTF_UNICODE/VK_PACKET outputs the wrong characters Sending unicode character via KEYEVENTF_UNICODE/VK_PACKET in SendInput outputs the wrong characters Apr 25, 2022
@lhecker
Copy link
Member

lhecker commented Apr 27, 2022

@miozus
Copy link

miozus commented Jun 18, 2022

the problem still appear.

,: => 翿

image

@lhecker lhecker added Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Product-Terminal The new Windows Terminal. Priority-2 A description (P2) labels Jun 18, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jun 18, 2022
@lhecker lhecker added this to the Terminal v1.16 milestone Jun 18, 2022
@lhecker
Copy link
Member

lhecker commented Aug 3, 2022

In conhost (the old terminal) this issue is caused by COOKED_READ_DATA and will take a while to fix (and it's outside of the scope of this issue).

In Windows Terminal I've narrowed this down to being caused by the Win32 Input Mode. You can work around this issue by adding "experimental.input.forceVT": true in your settings.json file (in the global global scope - this setting isn't per profile).

Edit: This is caused by MAX_PARAMETER_VALUE clamping the character parameter to 0x7fff.

@ghost ghost added the In-PR This issue has a related PR label Aug 4, 2022
@ghost ghost closed this as completed in #13667 Aug 4, 2022
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Aug 4, 2022
ghost pushed a commit that referenced this issue Aug 4, 2022
We must use 65535 as `MAX_PARAMETER_VALUE` in order for us to properly parse
win32-input-mode sequences, which transmit UTF-16 characters as parameters.

Closes #12977

## Validation Steps Performed
* Call `SendInput` with 🙁 (`L'\xD83D'`, `L'\xDE41'`)
* 🙁 appears on the input line ✅
DHowett pushed a commit that referenced this issue Aug 8, 2022
We must use 65535 as `MAX_PARAMETER_VALUE` in order for us to properly parse
win32-input-mode sequences, which transmit UTF-16 characters as parameters.

Closes #12977

## Validation Steps Performed
* Call `SendInput` with 🙁 (`L'\xD83D'`, `L'\xDE41'`)
* 🙁 appears on the input line ✅

(cherry picked from commit 74cdffe)
Service-Card-Id: 84772549
Service-Version: 1.15
@ghost
Copy link

ghost commented Aug 17, 2022

🎉This issue was addressed in #13667, which has now been successfully released as Windows Terminal v1.14.228.:tada:

Handy links:

@ghost
Copy link

ghost commented Aug 17, 2022

🎉This issue was addressed in #13667, which has now been successfully released as Windows Terminal Preview v1.15.228.:tada:

Handy links:

PKRoma pushed a commit to PKRoma/Terminal that referenced this issue Oct 15, 2022
We must use 65535 as `MAX_PARAMETER_VALUE` in order for us to properly parse
win32-input-mode sequences, which transmit UTF-16 characters as parameters.

Closes microsoft#12977

## Validation Steps Performed
* Call `SendInput` with 🙁 (`L'\xD83D'`, `L'\xDE41'`)
* 🙁 appears on the input line ✅

(cherry picked from commit 74cdffe)
Service-Card-Id: 84772549
Service-Version: 1.15
(cherry picked from commit f3f9eba)
Service-Card-Id: 84772548
Service-Version: 1.14
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants