Commands that erase the screen should clear the rendition attributes

[j4james]

Environment

Windows build number: Version 10.0.18362.239

Steps to reproduce

Open a WSL conhost shell, and execute the following command:

printf "\e[41;93;4;7m\e[2J\e[m"

This sets the text color to bright yellow on red, and enables the reverse video and underline attributes. It then clears the screen with an ED (erase in display) sequence.

Expected behavior

According to the VT510 reference, this should erase the lines "with all visual character attributes cleared". The DEC STD 070 manual says the same sort of thing: "the empty character (imaged as SPACE), the empty rendition, and the empty character attribute." Rendition refers to attributes like underline, reverse video, etc.

So when clearing the screen, I would expect the underline and reverse attributes not to be applied, so it should just fill the screen with the red background color (DEC's VT terminals never had color, but that's a requirement of the background color erase feature).

This is what the result looks like in XTerm:

Actual behavior

In the Windows console, though, the underline and reverse video attributes are applied, so the screen is filled with the yellow foreground color rather than the red background color, and every character on the screen also has a red underline.

More information

Note that this is an issue for a number of escape sequences. There are those that erase areas of the screen directly (ED, EL, ECH), and also some that reveal or delete areas of the screen as a result of scrolling (SU, SD, RI, IL, DL, ICH, DCH). If we're going to match the XTerm behaviour, then all of them should be filling the erased area with just the background color, and with none of the rendition attributes set.

It might seem like this could easily be fixed by clearing the META_ATTRS of the fill attribute in the calls to ScrollConsoleScreenBufferWImpl and FillConsoleOutputAttributeImpl. However, that would prevent those methods working correctly with RGB colors, since they rely on a hack that expects the fill attribute to be an exact match for the current text attribute (and that already has problems - see issue #832).

My proposal (not yet tested), is we replace the current hack with a much simpler hack, that just checks for a special case attribute value of 0xFFFF, which we declare to be the "background erase" color. When passed that value, the fill and scroll methods would simply convert that to the current value of SCREEN_INFORMATION::GetAttributes but with the meta attributes cleared. Its easy for the calling code to set, and doesn't require an expensive GenerateLegacyAttributes calculation on either side of the call.