-
Notifications
You must be signed in to change notification settings - Fork 9.2k
Ctrl+Break can leave the WSL shell in an unusable state #18425
Copy link
Copy link
Labels
Area-TerminalConnectionIssues pertaining to the terminal<->backend connection interfaceIssues pertaining to the terminal<->backend connection interfaceIssue-BugIt either shouldn't be doing this or needs an investigation.It either shouldn't be doing this or needs an investigation.Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirementsProduct-TerminalThe new Windows Terminal.The new Windows Terminal.
Milestone
Metadata
Metadata
Assignees
Labels
Area-TerminalConnectionIssues pertaining to the terminal<->backend connection interfaceIssues pertaining to the terminal<->backend connection interfaceIssue-BugIt either shouldn't be doing this or needs an investigation.It either shouldn't be doing this or needs an investigation.Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirementsProduct-TerminalThe new Windows Terminal.The new Windows Terminal.
Type
Projects
Status
To Cherry Pick
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
vim.:set mouse=ato enable mouse mode.press Enter to restartmessage, press Enter.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).