Ctrl+Break can leave the WSL shell in an unusable state

[j4james]

Windows Terminal version

1.22.2702.0

Windows build number

10.0.19045.5247

Other Software

VIM 8.2.4919 (inside WSL)

Steps to reproduce

1. Open the Settings, and set the Profile termination behavior to Close only when process exits successfully.
2. Start a WSL shell and run vim.
3. Enter :set mouse=a to enable mouse mode.
4. Press Ctrl+Break (possibly Ctrl+ScrLock depending on your keyboard).
5. When you see the press Enter to restart message, press Enter.
6. Once the shell restart, try clicking in the window to select some text.

Expected Behavior

I'd expect mouse selection to work.

Actual Behavior

When you click in the window, nothing can be selected, but a bunch of "random" characters get entered at the prompt. It seems that Ctrl+Break kills the session without giving the app a chance to exit gracefully, and then when we restart the session we don't reset any of the VT state either. As a result we're left with a mouse mode enabled which the shell wasn't expecting.

This mouse mode example was just the easiest to demonstrate, but you can see how it could be even more annoying if the app had enabled something like win32 input mode, or had selected a graphic character set.

Note that for Windows console apps this is less of a problem, because they can trap the break and block it, or at least shut down more gracefully. But I don't think there is anything that Linux apps can do about this, because it's the WSL session itself that is being aborted (at least that's what appears to be happening).

[WhatsACloud]

Managed to reproduce the bug on version 1.21.3231.0 of windows terminal, and version 23H2 of windows 11.

Bug also appears to go away if you enter vim, do :set mouse = a, then exit vim normally using :q.

will investigate further later.

[j4james]

You can also just type reset to get the terminal back to a usable state, but ideally that should be something the terminal does itself when restarting a session. In fact it would be best if it did that before it even displayed the process exit message, because otherwise that can be unreadable. So maybe at the start of this method, or wherever this is called from.

terminal/src/cascadia/TerminalConnection/ConptyConnection.cpp

Lines 442 to 453 in 25392ea

	void ConptyConnection::_indicateExitWithStatus(unsigned int status) noexcept
	{
	try
	{
	// GH#11556 - make sure to format the error code to this string as an UNSIGNED int
	const auto msg1 = RS_fmt(L"ProcessExited", _formatStatus(status));
	const auto msg2 = RS_(L"CtrlDToClose");
	const auto msg = fmt::format(FMT_COMPILE(L"\r\n{}\r\n{}\r\n"), msg1, msg2);
	TerminalOutput.raise(msg);
	}
	CATCH_LOG();
	}

It doesn't necessarily have to be be a hard reset, but at least a soft reset and then whatever additional modes are required to get the input back to normal.

[carlos-zamora]

Thanks for filing! RestartConnection() should fix this. Just a matter of calling the API on our end. 🙂

[WhatsACloud]

I'll fix this issue and submit a PR for it by this week.

[WhatsACloud]

@carlos-zamora I tried running RestartConnection() from the command palette but it doesn't appear to fix the issue.

What do you think of running the command "reset" when the user presses ctrl + break (but before the SIGKILL is sent), or after the user presses "enter" to restart?

[WhatsACloud]

Fixed this issue in this PR