History window partially invisible when switching from bash to cmd.exe

[j4james]

Environment

Windows build number: Version 10.0.18362.356

Steps to reproduce

1. Open a bash shell in a conhost window.
2. Press enter a few times until you reach the bottom of the viewport.
3. Run cmd.exe to switch to a cmd shell.
4. Run the ver command, just to get something in the command history.
5. Press F7 to view the history.

Expected behavior

I'd expect the history window to popup showing the ver command I'd just entered.

Actual behavior

The history window does open, but part of it is invisible. It appears to be cut off at the point where the console transitioned from the bash shell to the cmd shell.

[DHowett-MSFT]

Yes! Somebody finally reported it! 😁

This is an unfortunate consequence of WSL using ConPTY for interop with windows binaries and passing the PSEUDOCONSOLE_INHERIT_CURSOR flag.

What you end up with is two console hosts:

the one on the right owns drawing the history for CMD. Since it's acting like the buffer starts halfway down the screen (a point that changes with every line drawn), it will only redraw that region as it's the only region it has a backing buffer for.

[DHowett-MSFT]

FWIW: since history is owned by conhost, and only the rightmost conhost knows CMD's history, and it cannot know what's in the buffer above it (red) I'm not sure what we can really do here. It can't redraw what it doesn't know about, and there's no affordance for WSL telling it what belongs there. If we could invent a VT way to delegate history to a wrapping conhost, that would work but I'd rather not dig in deeper on the whole "console host or terminal knows about the command history" design...

[j4james]

That's interesting. I had no idea that was what was happening behind the scenes. And this is really an edge case, so I personally wouldn't have any objections to closing the issue as wont-fix.

That said, I was wondering if there wasn't a way to make it fail in a more usable way. I've just tried making a little console app that writes to the wsl half of the screen, and it does seem to work. I understand that it wouldn't be able to restore the area of the screen that it was writing over, but that seems less of an issue than not showing anything at all. It's still not clear to me why a console app can write to that part of the screen, but the history menu can't.

[DHowett-MSFT]

That said, I was wondering if there wasn't a way to make it fail in a more usable way.

Yeah, we definitely can. We'll probably take a slightly different approach, though.

We chatted about this one and decided that data integrity in the buffer is of utmost importance, so we don't want to write over a part of the screen that we can't restore. To that end, we've decided on (something like) this:

[DHowett-MSFT]

(mspaint to the rescue!)

[j4james]

I'd definitely be happy with this as a solution. It was one of the options I tried myself, but I couldn't get it to work.

[DHowett-MSFT]

Hmm... it looks like the "virtual top" here is a fabrication of the conpty VT renderer: it just drops dirty rects that are out of range.

That probably needs to be communicated to something in a different layer so it can make the decision in Popup to squash the available size...

[DHowett]

Funny enough, we fixed this with #17445!