Description
On Windows 10 1903 (build 18362.86), but could be the same on other build, I didn't test on earlier ones or 20H1.
Launching a WSL distribution opens a console window and connects it as a tty* to the instance.
If an edit selection is marked before the client process gets connected, for example by click and drag over the window client area right when it appears in QuickEdit Mode, before any output gets displayed, the output is paused until the selection is cancelled or copied.
In that state, trying to close the console window using the [X] button does not close the console, and instead seems to queue the WM_CLOSE until the output is resumed by cancelling or copying the selection.
This means if a user triggers a selection before the shell gets displayed, the close button seems ineffective until they first resolve the selection issue, at which point the window gets closed even if the user changed their mind. In QuickEdit Mode, if a selection is triggered by mistake, it might not be obvious to the user, and pressing the close button several times has no effect.
In the state shown in the screenshot, the close button does not work :
This only seems to happen with WSL distributions, probably because Win32 CUI processes are always started before a console gets created or attached to their process, making it always ready to process WM_CLOSE, while in WSL the console gets created before the shell process gets started and connected to it.
Current behavior: Pressing the close button does nothing while in selection mode, and when selection is over, the window gets closed even if user doesn't press the close button again.
Expected behavior: Pressing the close button should always be a reliable way to close a console window.
Instead of an ineffective close button that only reacts asynchronously once the selection is over, pressing the close button (or processing a WM_CLOSE sent by another process to the console window's message queue) should automatically cancel any selection underway, similar to how the selection gets cancelled if a keypress gets processed.
This wouldn't change the behavior for Win32 CUI processes, and would resolve the issue for WSL instances.
Activity