Terminal: Cursor Keys get stuck in Normal Mode in Git for Windows; DECCKM has no effect

[KalleOlaviNiemitalo]

Environment

Windows build number: Microsoft Windows NT 10.0.19041.0
Windows Terminal version (if applicable): Windows Terminal Preview 1.1.1671.0
Git for Windows 2.27.0

Profile:

{
    "guid": "{dc9f4186-52a8-4b9f-a659-0c438c764b58}",
    "commandline": "\"%ProgramFiles%\\Git\\bin\\bash.exe\" -i -l",
    "name": "Git Bash",
    "icon": "%ProgramFiles%\\Git\\mingw64\\share\\git\\git-for-windows.ico",
    "hidden": false
}

TERM=xterm-256color by default.

MSYS=enable_pcon because pseudoconsoles were enabled when Git for Windows was installed.

Steps to reproduce

1. Delete the Ctrl+C and Ctrl+V key bindings in settings.json.
2. Either start the profile shown above, or start the Command Prompt profile and run "C:\Program Files\Git\bin\bash.exe" in CMD.
3. Run less /etc/package-versions.txt in Bash.
4. Press the Down arrow key and note that the file scrolls OK.
5. Press q to exit less.
6. Run cat in Bash.
7. Press Ctrl+C to terminate cat.
8. Run less /etc/package-versions.txt in Bash.
9. Press the Down arrow key.

Expected behavior

The file scrolls again, like before.

Actual behavior

The file does not scroll. Instead, ESC[ briefly flashes on the bottom line.

If you then open a new tab, arrow keys work OK in that tab.

Cause

The ENABLE_VIRTUAL_TERMINAL_INPUT mode is left disabled when cat is terminated. This causes ReadConsoleInputW to return virtual keys such as VK_DOWN, rather than console virtual terminal sequences. MSYS then translates the VK_DOWN to the normal-mode sequence ESC [ B, but less expects the application-mode sequence ESC O B.

[KalleOlaviNiemitalo]

I opened another tab with the Git Bash profile and the https://github.com/microsoft/terminal/issues/3206 debug feature, and ran the PS1='$ ' and printf "\033[?1h" commands. I did not see ␛[?1h in the debug pane.

Then, I attached WinDbg to the bash.exe process, set a breakpoint in kernelbase!WriteConsoleW, and ran the command again. I got a call in which nNumberOfCharsToWrite = @r8 = 5 and lpBuffer = @rdx = L"\x1B[?1h".

After that, I disabled the breakpoints and pressed Ctrl+V and Up. That displayed ^[OA, i.e. cursor keys were in application mode.

This indicates that, when the problem is not occurring, printf "\033[?1h" correctly writes the control sequence to the console, but it is handled in the console host and not in Windows Terminal. Because the debug pane shows the I/O between Windows Terminal and the console host, rather than between the console host and applications, it will not be very useful for further analysis.

The next time the problem recurs, I should attach a debugger again and check what arguments the process is passing to WriteConsoleW and SetConsoleMode.

[KalleOlaviNiemitalo]

Perhaps related to https://github.com/microsoft/terminal/issues/6054, but that one was already closed.

[akrieger]

I closed it because I couldn't get a consistent repro nor could I even conclusively determine what the problem was, despite hours of trying and messing around in termcaps and reinstalling this or that and jumping between terminal emulators. And my original issue claim was simply _installing_ WT messed up my unrelated terminal setup. Absent any sort of repro conditions I couldn't leave the issue open in good faith.

[KalleOlaviNiemitalo]

WinDbg shows that both less.exe and bash.exe read keyboard input via ReadConsoleInput; not via ReadConsole nor ReadFile. This is regardless of whether the problem is occurring.

When the problem is occurring, the console input handle has mode 0x9 during the ReadConsoleInputW call. This does not include ENABLE_VIRTUAL_TERMINAL_INPUT = 0x200. ReadConsoleInputW then gets VK_UP in an INPUT_RECORD structure. I guess some MSYS library then translates that to ESC [ A without knowing that the application previously sent DECCKM to the terminal.

When the problem is not occurring, the console input handle has mode 0x209 during the ReadConsoleInputW call. This includes ENABLE_VIRTUAL_TERMINAL_INPUT = 0x200. ReadConsoleInputW then gets ESC O A in three INPUT_RECORD structures.

So the problem is that something clears ENABLE_VIRTUAL_TERMINAL_INPUT and nothing sets it afterwards. That may be a bug in MSYS. Anyway, I presume https://github.com/microsoft/terminal/issues/4954 would fix it for good.

I don't think this needs any changes in Windows Terminal other than already described there.

[KalleOlaviNiemitalo]

I thought I'd attach a debugger to OpenConsole.exe and set a conditional breakpoint in ApiDispatchers::ServerSetConsoleMode, to find which program is clearing ENABLE_VIRTUAL_TERMINAL_INPUT and why. Is OpenConsole.pdb available from somewhere or would I have to build it locally?

[DHowett]

Which version?

[KalleOlaviNiemitalo]

Windows Terminal Preview 1.1.1671.0 x64

[DHowett]

OpenConsole_1.1.1671.0_dbgsym.zip

Enjoy! Source commit is c1076a8.

[DHowett]

Backstory

When an application hosted in a pseudoconsole requests ENABLE_VIRTUAL_TERMINAL_INPUT, it gets wired up directly (or nearly directly) to its controlling terminal. Conhost's input transformer (OpenConsole!*TerminalInput*) gets out of the way completely. In Windows Terminal, TerminalControl!*TerminalInput* takes over. It's the same code, but on the terminal side instead of the console host side.

It also gets "selective output passthrough" enabled: when it emits a DECSET or DECRST 1, 66, 100x (mouse), or 9001 that request is sent directly through to the controlling terminal as well. This is so that the controlling terminal generates the right _input_ (since it's been wired up directly to the VT input queue in the client process.)

We used to have an issue where the pseudoconsole's input queue couldn't handle the SS3 cursor key sequences. We fixed that in #3383.

[KalleOlaviNiemitalo]

MSYS is toggling ENABLE_VIRTUAL_TERMINAL_INPUT on and off all the time.

Anyway, here is one case where the mode is left off:

1. Delete the Ctrl+C and Ctrl+V key bindings in settings.json.
2. Start the Command Prompt profile in Windows Terminal.
3. Run "C:\Program Files\Git\bin\bash.exe" in CMD.
4. Run printf "\033[?1h" in Bash.
5. Press Ctrl+V and Up in Bash. Note that ^[OA is displayed. Erase that.
6. Run cat in Bash.
7. Press Ctrl+C to terminate cat.
8. Run printf "\033[?1h" in Bash.
9. Press Ctrl+V and Up in Bash. Note that ^[[A is displayed.

The same happens in both Windows Terminal 1.0.1401.0 and Windows Terminal Preview 1.1.1671.0.