-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
ConPTY does not translate arrow keys with +ENHANCED_KEY in their modifiers #2397
Comments
Any help? |
We believe this is a bug, but we're not really sure what the root cause is. Presumably something about how ConPTY builds We're also very confused that |
Before the 1903 version of Windows, the return value was b'\xe0' b'K', which became b'\x00' b'K' when upgraded to 1903, causing some programs to fail. |
Eureka! Under normal circumstances:
Under ConPTY:
Critical here is The documentation on
|
And now that we have a root cause, I'm finally renaming this issue. |
Yanking the triage tag after a discussion with @carlos-zamora and @zadjii-msft. Carlos is down to look at this 😄 |
This also prevents PDCurses from recognizing the cursor keys, as I just discovered. |
So, the program written before runs unnormal. |
## Summary of the Pull Request ConPty did not set the ENHANCED_KEY flag when generating new input. This change helps detect when it's supposed to do so, and sends it. ## References [Enhanced Key Documentation](https://docs.microsoft.com/en-us/windows/console/key-event-record-str) ## PR Checklist * [X] Closes #2397 ## Detailed Description of the Pull Request / Additional comments | KEY_EVENT_RECORD modifiers | VT encodable? | Detectable on the way out? | |----------------------------|---------------|----------------------------| | CAPSLOCK_ON | No | No | | ENHANCED_KEY | No | Yes** | | LEFT_ALT_PRESSED | Yes* | Yes* | | LEFT_CTRL_PRESSED | Yes* | Yes* | | NUMLOCK_ON | No | No | | RIGHT_ALT_PRESSED | Yes* | Yes* | | RIGHT_CTRL_PRESSED | Yes* | Yes* | | SCROLLLOCK_ON | No | No | | SHIFT_PRESSED | Yes | Yes | ``` * We can detect Alt and Ctrl, but not necessarily which one ** Enhanced Keys are limited to the following: - off keypad: INS, DEL, HOME, END, PAGE UP, PAGE DOWN, direction keys - on keypad: / and ENTER Since we can't detect the keypad keys, those will _not_ send the ENHANCED_KEY modifier. For the following CSI action codes, we can assume that they are Enhanced Keys: case CsiActionCodes::ArrowUp: case CsiActionCodes::ArrowDown: case CsiActionCodes::ArrowRight: case CsiActionCodes::ArrowLeft: case CsiActionCodes::Home: case CsiActionCodes::End: case CsiActionCodes::CSI_F1: case CsiActionCodes::CSI_F3: case CsiActionCodes::CSI_F2: case CsiActionCodes::CSI_F4: These cases are handled in ActionCsiDispatch ``` ## Validation Steps Performed Followed bug repro steps. It now matches!
🎉This issue was addressed in #5021, which has now been successfully released as Handy links: |
Thank you! I can finally get rid of |
Great! |
When we added support for win32 input mode, we neglected to pass `ENHANCED_KEY` through the two surfaces that would generate events. This broke arrow keys in much the same way was #2397, but in a different layer. While I was working on the WPF control, I took a moment to refactor the message cracking out into a helper. It's a lot easier on the eyes than four lines of bit shifting repeated three times. Fixes #7074
When we added support for win32 input mode, we neglected to pass `ENHANCED_KEY` through the two surfaces that would generate events. This broke arrow keys in much the same way was #2397, but in a different layer. While I was working on the WPF control, I took a moment to refactor the message cracking out into a helper. It's a lot easier on the eyes than four lines of bit shifting repeated three times. Fixes #7074 (cherry picked from commit dd0f7b7)
When we added support for win32 input mode, we neglected to pass `ENHANCED_KEY` through the two surfaces that would generate events. This broke arrow keys in much the same way was #2397, but in a different layer. While I was working on the WPF control, I took a moment to refactor the message cracking out into a helper. It's a lot easier on the eyes than four lines of bit shifting repeated three times. Fixes #7074 (cherry picked from commit dd0f7b7)
Today I updated Windows to 1903 and found that a python program I had written earlier ran incorrectly.
The brief test code is as follows:
When I run the above code in native powershell, press ← key when collecting characters, and it will print
b'\xe0' B 'K'
, and the same code running in the terminal returnsb'\x00' b'K'
.This problem didn't appear in the last version of Windows (18.xx).
Steps to Reproduce:
A related issue on vscode:
microsoft/vscode#78682
Thank you for your attention.
The text was updated successfully, but these errors were encountered: