Weird blue selection after closing neovim (WSL) #5404

@DHowett-MSFT commented on GitHub (Dec 5, 2019):

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

@DHowett-MSFT commented on GitHub (Dec 5, 2019): I bet @j4james has an inkling as to what's happening here :grin:

claunia commented

@j4james commented on GitHub (Dec 5, 2019):

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:

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.
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.
Have you customised the default colors, the color palette, or anything like that?

@j4james commented on GitHub (Dec 5, 2019): 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?

claunia commented

@schffp commented on GitHub (Dec 5, 2019):

@j4james

It's the new Windows Terminal, I just have it set to open WSL/Ubuntu as default and disabled the tab bar.
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.
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.

@schffp commented on GitHub (Dec 5, 2019): @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 **neo**vim 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. ![vim](https://user-images.githubusercontent.com/35227426/70277478-c4b47600-17b2-11ea-803d-ea294a3117f4.png)

claunia commented

@j4james commented on GitHub (Dec 5, 2019):

@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 commented on GitHub (Dec 5, 2019): @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.

claunia commented

@j4james commented on GitHub (Dec 6, 2019):

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.

@j4james commented on GitHub (Dec 6, 2019): 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.

claunia commented

@DHowett-MSFT commented on GitHub (Dec 6, 2019):

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

@DHowett-MSFT commented on GitHub (Dec 6, 2019): @j4james thanks for digging into this :smile: we really appreciate it

claunia commented

@j4james commented on GitHub (Dec 8, 2019):

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.

@j4james commented on GitHub (Dec 8, 2019): 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](https://github.com/microsoft/terminal/blob/5c43f055c508a00b24608df3d8640b00f04ed826/src/host/screenInfo.cpp#L1416-L1419) 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.

claunia commented

@s10g commented on GitHub (Feb 26, 2020):

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=

@s10g commented on GitHub (Feb 26, 2020): 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=```

claunia commented

@jdebp commented on GitHub (Feb 27, 2020):

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

@jdebp commented on GitHub (Feb 27, 2020): That's two other, different, issues: #3684 and #1604.

claunia commented

@jazzdelightsme commented on GitHub (Apr 19, 2021):

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.

@jazzdelightsme commented on GitHub (Apr 19, 2021): 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: ![image](https://user-images.githubusercontent.com/771085/115280423-c5764f80-a0fc-11eb-83b5-40f4af5ed55e.png) 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.

claunia commented

@mingsxs commented on GitHub (Apr 20, 2021):

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......

@mingsxs commented on GitHub (Apr 20, 2021): 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......

claunia commented

@zadjii-msft commented on GitHub (Apr 20, 2021):

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.

@zadjii-msft commented on GitHub (Apr 20, 2021): 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.

claunia commented

@j4james commented on GitHub (Apr 20, 2021):

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.

@j4james commented on GitHub (Apr 20, 2021): 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.

claunia commented

@mingsxs commented on GitHub (May 11, 2021):

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.

@mingsxs commented on GitHub (May 11, 2021): 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.

claunia commented