Terminal: Alt-Backspace followed by Enter does not behave properly

[kylewlacy]

Pressing Alt+Backspace, then some other characters, followed by Enter will not trigger the right inputs for a shell through WSL. This issue is pretty subtle and it can be tricky to observe in my experience, so I have 2 test cases below to demonstrate this issue.

Environment

Windows build number: 10.0.18362.0
Windows Terminal version (if applicable): 0.4.2382.0 (latest available on the Windows Store)

Any other software? Ubuntu 18.04.3 LTS in WSL 1; Linux Mint with GNOME Terminal 3.28.1

Test case 1

Steps to reproduce

1. Open a Bash terminal
2. Type echo foo (don't press Enter)
3. Press Alt+Backspace to delete the word (the command should now read echo)
4. Type bar (the command should now read echo bar)
5. Press Enter

Expected behavior

bar should be printed. This is the behavior when using WSL via vanilla Command Prompt, or using GNOME Terminal on a standalone Linux distro.

Actual behavior

Nothing happens. Pressing Alt+Backspace then pressing Enter inputs an escape sequence that would be expected from Alt+Enter, which Bash silently ignores by default.

To see this more visibly, run bind -x '"\e\r":"echo whoops"' then repeat the above steps. Now, whoops will be printed, since the above steps will input the escape sequence for Alt+Enter (\e\r).

Test case 2

Steps to reproduce

1. Open a Bash terminal
2. Run cat > sample.txt
3. Type foo followed by Alt+Backspace followed by bar followed by Enter
4. Press Ctrl+D to return to the prompt
5. Run hexdump -C sample.txt

Expected behavior

hexdump should print the following output:

00000000  66 6f 6f 62 61 72 0a                              |foobar.|
00000007

This is the behavior when using WSL via vanilla Command Prompt, or using GNOME Terminal on a standalone Linux distro.

Actual behavior

hexdump prints the following output:

00000000  66 6f 6f 62 61 72 1b 0a                           |foobar..|
00000008

Just like before, we can see the sequence for Alt+Enter (\e\r, or 1b 0a in hex) is actually registered where we expected to see just \r (0a in hex).

[DHowett-MSFT]

Looks like we're carrying the Alt key state through to the next INPUT_RECORD. This reproduces with putty-wincon as well, so it's a conpty issue!

^      27 0033 0x1b
        127 0177 0x7f
^[^M     27 0033 0x1b
         13 0015 0x0d

[DHowett-MSFT]

Looks like recrudescence of #1209

[msftbot[bot]]

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

Handy links:

• Release Notes
• Store Download

[DHowett-MSFT]

Hey! The fix for this went out in Windows in the Insider channel's Fast Ring with build 19013. It's worked in Windows Terminal since v0.6, and now it'll work in other terminals using ConPTY on Windows.