Weird blue selection after closing neovim (WSL)

[schffp]

Environment

Windows build number: Microsoft Windows Version 10.0.18362.476
Windows Terminal version: microsoft-windows-terminal 0.7.3291.0

Steps to reproduce

1. Open terminal in wsl mode
2. Open neovim
3. Resize the window
4. Quit neovim

Actual behavior

A weird blue "selection" appears
clear gets rid of it

[DHowett-MSFT]

I bet @j4james has an inkling as to what's happening here 😁

[j4james]

I was just looking at this, because I thought I knew what it was, but I'm not so sure now. 😄 I thought it might be related to #2540, but I can't reproduce this exact scenario.

A couple of questions for @schffp:

1. When you say "open terminal in WSL mode", what exactly does that mean? That screenshot doesn't look like the new Windows Terminal app, but then again it doesn't look like the old conhost shell either, so I'm not sure what it is.
2. Do you have to run vim to reproduce the problem? I know resizing the window can do some weird things to the background colors, but the problems I know off wouldn't require that you run vim to trigger the issue.
3. Have you customised the default colors, the color palette, or anything like that?

[schffp]

@j4james

1. It's the new Windows Terminal, I just have it set to open WSL/Ubuntu as default and disabled the tab bar.
2. You have to run neovim to be specific. I just tried it vim and nano and I couldn't reproduce this exact bug with those. I've found something else though. If you ls -lah then enter vim/nano, then resize, then exit vim/nano, the 777 background color stretches over the whole terminal width. I've attached a screenshot.
3. I've customized the background color to match my neovim color scheme. The terminal color scheme is Campbell (which I believe is default).

PS: I've just cleared out my whole nvim config file. Same bug, but the "selection" is white now.

[j4james]

@schffp Thanks for those details. I can reproduce it now.

The green bars are a known issue (#32). And I think #293 and/or #2661 may have something to do with the exact colors you're seeing. But I need to do a bit more digging to find out what is going on with the nvim resizing side of things. That may be something new.

[j4james]

Just a quick status update before I go to sleep. #2540 is partly to blame, and fixing that should address this issue too, but that's really just covering up a deeper problem. Namely that a resize operation fills the lower part of the buffer with the active attributes, which I'm pretty sure is wrong.

And it's possible #399 may be a related issue - if not the same - although I haven't had a chance to look at that in much detail yet.

[DHowett-MSFT]

@j4james thanks for digging into this 😄 we really appreciate it

[j4james]

The short answer to this is you need to use the default attributes (i.e. TextAttribute{}) in place of GetAttributes() when initialising the new text buffer when resizing.

The long answer is more complicated. Sometimes the initial buffer is initialized as legacy white on black, rather than the default colors, and in those circumstances it would be more correct for the resize to use those same colors. And in theory, it's possible that the forward buffer could be filled with a whole range of different colors, in which case the resize should really be trying to preserve those colors in whatever way makes the most sense for a reflow (at the very least that should be done for the visible viewport). And anything not covered by that reflow should probably use the same colors as the bottom right corner (of the buffer, not the viewport).

99% of the time, though, the default attributes are going to be the right choice, so that's at least a reasonable short-term improvement.

[s10g]

Just a tidbit related to this. When I run neovim, neovim will change the cursor from WT-set "vintage" to neovim-set block cursor (filledRectangle?). When exiting neovim, cursor stays as block cursor instead of returning to vintage cursor.

After having started and exited neovim to produce this "lingering" block cursor, the terminal starts doing weird things; the closest I could describe it as is that some escape sequences are lingering and not cleaned up properly.

I don't know where the fault lies, but at least this neovim-setting seems to fix it for now, which tells neovim to not change the cursor shape at all:
set guicursor=

[jdebp]

That's two other, different, issues: #3684 and #1604.

[jazzdelightsme]

Another potential repro:

When pwsh is out-of-date, it prints out a "hey you should get the new one" banner when it starts (the banner has a different background). If I double-click Terminal’s title bar to maximize it at juuuuust the right time while it is starting, I get some funky spillage of the background color:

If I then “restore” the window, everything goes back to normal. And then if I maximize again, it doesn’t go back to the funky view—it still looks normal.

[mingsxs]

Sorry but this issue still exists in the latest build, and this issue can be really annoying, it will be very grateful that it can be fixed in next release......

[zadjii-msft]

Sorry, but I don't have the time this month to loop back on #5792 and do the due diligence to make sure that's the right fix. Usually I'd trust @j4james for help with those sorts of things, he might be able to give me a sanity check. Maybe we could just toss that in (before the bug bash friday...? @DHowett) and see how it feels. Less risky now that we're in the 2.0 "break everything" phase rather than the high-bar-for-1.0-release phase. It's been just about a year since I authored that PR so I don't really have the context anymore, unfortunately.

[j4james]

I'm still not in a position where I can do any real testing, but I believe PR #5792 is the right move. I was initially somewhat concerned (back in 2019) that the buffer should be initialized with white on black in some cases, but that was addressed in PR #6698, so all shells should be initializing with default attributes now.

[mingsxs]

Sorry for the late reply, it's okay, I commented on this issue just for your awareness since this issue could really impact us as users.

[ghost]

🎉This issue was addressed in #5792, which has now been successfully released as Windows Terminal Preview v1.9.1445.0.:tada:

Handy links:

• Release Notes
• Store Download