Console background color has strange behavior when changed from a program

[jgonzalezdr]

Environment

Windows build number: Microsoft Windows [Versión 10.0.18363.1139]
Windows Terminal version (if applicable): 1.3.2651.0

Any other software?

Steps to reproduce

Take a program that changes the console background using Win32 API calls like the following, and execute it several times:

#include "windows.h"

void WriteToConsole( HANDLE handle, const char* text )
{
    WriteConsole( handle, text, (DWORD) strlen(text), NULL, NULL );
}

void main( int argc, const char* argv[] )
{
    HANDLE handle =  GetStdHandle( STD_OUTPUT_HANDLE );
    CONSOLE_SCREEN_BUFFER_INFO consoleInfo;
    GetConsoleScreenBufferInfo( handle, &consoleInfo );


    WriteToConsole( handle, "0: Default color\n" );
    SetConsoleTextAttribute( handle, FOREGROUND_BLUE | FOREGROUND_INTENSITY | BACKGROUND_RED | BACKGROUND_GREEN );
    WriteToConsole( handle, "1: Blue over brown\n" );
    WriteToConsole( handle, "2: Blue over brown\n" );
    SetConsoleTextAttribute( handle, FOREGROUND_RED | FOREGROUND_INTENSITY | BACKGROUND_BLUE | BACKGROUND_GREEN );
    WriteToConsole( handle, "3: Red over cyan\n" );
    WriteToConsole( handle, "4: Red over cyan\n" );
    WriteToConsole( handle, "5: Red over cyan\n" );

    SetConsoleTextAttribute( handle, consoleInfo.wAttributes );
}

Expected behavior

When a background color is set and then a text shorter than the console width is written followed by a newline, the remaining background color until the right margin should be transparent (showing the underlying console's background - black by default or whatever background color the user has configured), as it happens in cmd consoles; or even filling with the same color that was just set previously from the app could be acceptable.

Actual behavior

The wrong behavior described thereafter does not happen all the time, the first time that a new console is opened or after executing the cls command the behavior is right, but after a few executions (less than 10) the wrong behavior begins.

The wrong behavior consists in that after a background color change the next time that a newline is written , the remaining background color until the right margin is filled with the background color that was set previous to the last color change (n-1), and then after this it behaves normally (like cmd, not filled with a solid color).

When the program execution finishes, the background color of the last empty line is drawn with the last color that was set, but this is inconsistent with the behavior of the previous lines (it should be transparent).

[zadjii-msft]

Hmm, so this isn't #3848, because this doesn't have to do with resizing.

This does sound awfully a lot like #7360, which was by design, but that was for attributes written by VT sequences. Since you're using the legacy console APIs here, this probably shouldn't have changed...

Though, I doubt that we'll be able to differentiate between these two cases (writing this test with VT vs Win32 APIs). Even if conhost could differentiate, I'd bet that conpty is gonna blend them into the same VT emitted for the Terminal to use.

[jgonzalezdr]

Just in case it may help to track down the bug, I've discovered that if I resize the window, the console is redrawn with a proper behavior, filling with the active background color until the right margin. This behavior after resizing is not the same than cmd, but it is coherent (I assume that this is the intended behavior).

Before resizing:

After resizing:

[zadjii-msft]

Note to self - this still repros in 1.11, even after #5792.

Though, this does repro at the bottom of conhost's buffer, even without the Terminal. I think this is going to have to be by-design for the Terminal. New lines are going to get initialized with whatever the current attributes are. We could have theoretically scoped a change to "if the console doesn't have VT mode enabled, then don't initialize lines with the current attributes", but even that wouldn't work right here. We enable VT by default for apps running in the Terminal. The app would have to specifically turn VT off. I guess that means this actually was a /dup of #7360

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!