Shift key not working properly in some situations

[iCodeSometime]

Environment

Windows build number: 10.0.18362.0
Windows Terminal version (if applicable): 0.4.2382.0

Any other software? wsl + emacs

Steps to reproduce

1. Open emacs within wsl in Windows Terminal.
2. Type either of the following:
   • M-> (alt + greater than) to move to the end of the file
   • M-< (alt + less than) to move to the beginning of the file
3. Verify the key emacs is seeing, by typing C-h k (Ctrl+h, k) for describe key - then type either of the above key combinations.

Expected behavior

M-> moves to the end of the file.
M-< moves to the beginning of the file.
C-h k M-> displays M-> as the command run.
C-h k M-< displays M-< as the command run.

Actual behavior

M-> does not move to the end of the file.
M-< does not move to the beginning of the file.
C-h k M-> displays M-. as the command run.
C-h k M-< displays M-, as the command run.

[iCodeSometime]

To be clear, this all works properly when I use my wsl instance from outside of the new windows terminal app.

[zadjii-msft]

I'm moving this to the Terminal 1.0 milestone because it seems this only repros in the Windows Terminal. It doesn't repro if you use WSL to launch cmd.exe, then launch wsl emacs. That set of steps would activate conpty. Since it doesn't repro with conhost acting as the terminal, we can rule our conpty as the source of the bug.

It'll still get fixed, but we don't need to worry about getting it into the OS for 20H1.

IIRC @lhecker did some work in this area previously.

[lhecker]

@zadjii-msft Yeah this problem is basically tangential to the AltGr issues.
We have the vkey and modifier states in the UWP code readily available, but when we map it for the old NT console subsystem we throw away the modifier states here:

terminal/src/cascadia/TerminalCore/Terminal.cpp

Line 225 in 7128e87

ch = static_cast<wchar_t>(LOWORD(MapVirtualKey(vkey, MAPVK_VK_TO_CHAR)));

This causes the logic here to malfunction where the assumption is made that the char data is already pretranslated:

terminal/src/terminal/input/terminalInput.cpp

Line 428 in 7128e87

_SendEscapedInputSequence(keyEvent.GetCharData());

Due to this I added the circumvention logic for AltGr in the UWP side of things. I guess it's time to find a proper solution for this?

[lhecker]

I read up on this a bit and it appears to me that we can map the vkey to the pretranslated character using a combination of MapVirtualKey(vkey, MAPVK_VK_TO_VSC) with ToUnicode(...).
Afterwards we should be able to remove the special handling for AltGr.

(I still don't quite understand the full architecture, but I keep wondering for what technical reason the terminalInput class is being used. If it's just for code sharing purposes, we should probably split the input handling up, so we don't have to rely on the above.)

[DHowett-MSFT]

Fixed in #2836.

[ghost]

🎉This issue was addressed in #2836, which has now been successfully released as Windows Terminal Preview v0.5.2762.0.:tada:

Handy links:

• Release Notes
• Store Download