This seems to be a by-design behavior in the .NET and terminal perspective. The problem is that we are writing out the newline along with the text, so the restoring of the original background color doesn't happen until after the newline gets written out. When it's at the last line in terminal, that newline triggers a buffer scroll when the background color is still Blue, and that's why the newly added line also has the Blue background color, hence the leak.

It works fine in Windows PowerShell because it writes out newline in a different Write call, where foreground and background are not changed.

So, I think maybe the right fix is to check if we are at the end of terminal before writing in Host, and if so, write out the newline in a separate call without changing the foreground and background.

@daxian-dbw Windows PowerShell doesn't use VT, so the behavior is different for the Console API. If the VT background sequence exists and you write a newline by itself, the entire line after the newline will have the background color. You can see this in zsh/bash:

echo -e "\e[44m1\n2"

So writing a newline in a separate call w/o reseting will result in a whole line with that decoration.

This behavior is not related to VT decorations, and I can reproduce it with the following C# code as a console application:

// See https://aka.ms/new-console-template for more information

ConsoleColor bg = Console.BackgroundColor;
Console.BackgroundColor = ConsoleColor.Blue;

try {
    Console.WriteLine("Hello, World!");
}
finally {
    Console.BackgroundColor = bg;
}

If I choose to write the newline in a separate call, after restoring the background color, then it will work as expected.
This is what Windows PowerShell does.

// See https://aka.ms/new-console-template for more information

ConsoleColor bg = Console.BackgroundColor;
Console.BackgroundColor = ConsoleColor.Blue;

try {
    Console.Write("Hello, World!");   // <= write out the text, no newline
}
finally {
    Console.BackgroundColor = bg;
}

Console.WriteLine();   // write out the newline after the restoring of background/foreground color

But this doesn't mean this problem doesn't exist in Windows PowerShell, you can reproduce it in Windows PowerShell by running write-Host "hello`n" -BackgroundColor Red at the last line of the terminal window:

I see. I misunderstood what you meant previously. I'll make the change. Note that if you use Write-Output with content including VT, I need the other change to reset anyways.

@SteveL-MSFT, I'm just thinking aloud here, still not sure what is the right fix yet.
If we care about non-VT terminals, then we should consider do what Windows PowerShell does -- use a separate write for the newline, without changing foreground/background when writing.

As for VT decoration, when writing out "`e[44m1`n2" in PowerShell, it leaks background color even if it's not at the last line of the terminal:

So, the question is -- is that the expected behavior? The user may intentionally omit the Reset sequence, but should be rare.
If that is not the desired behavior, then we should prepend the Reset sequence to the prompt we write out, to avoid the leak (not super sure if that would be the right fix though, let me know what you think).

@daxian-dbw the current fix has the same behavior as in zsh. The first here is the fix, the second zsh, the last current pwsh.

This PR has 18 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Label      : Extra Small
Size       : +12 -6
Percentile : 7.2%

Total files changed: 2

Change summary by file extension:
.cs : +8 -2
.ps1 : +4 -4

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

I'll hold off on fixing the test issues until we agree on how this should be fixed

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

Has there been any continued discussion on how this should be fixed? This is painful for enhanced prompt tools like oh-my-posh, too, when working in Powershell.

I really dislike manipulating ConsoleColor directly, as it has given me trouble when trying to fix #18003 . Can we not switch to OSC sequences from $PSStyle instead?

This is waiting on WG-Interactive to discuss and make a decision

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author