Type: Bug

When using ANSI escape sequences to format the input of a C++ program as seen in the terminal and then clear that formatting before the next input prompt, if there is more than one such prompt anywhere in the program, seemingly regardless of anything else, the background formatting will “spill over” into the blank whitespace past \e[0m until the end of the next line, that is the right edge of the integrated terminal, except for any text, including spaces, that may be on that line, which is either unformatted or has its own formatting.

This issue occurs with GPU acceleration set to either WebGL or 2D canvas, but not when it's disabled. This issue, oddly enough, also occurs in GNOME Terminal , but not XTerm. Note that XTerm gives incorrect colors with two colons after 38:2 and 48:2, but the integrated terminal does so when there is only one, so they are in direct conflict unless one wants to just swap all of the colons for semicolons.

Yes, this is reproducible with all of the extensions temporarily disabled.

Here's a minimal test case:

#include <iostream>

using namespace std;

int main() {
    int one, two, three;

    cout << "Test one: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> one; cout << "\e[0m"
         << "Test two: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> two; cout << "\e[0m"
         << "Test three: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> three; cout << "\e[0m\n"

         << "Variable one: \e[38:2::102:51:153;48:2::255:240:245m" << one << "\e[0m\n"
         << "Variable two: \e[38:2::102:51:153;48:2::255:240:245m" << two << "\e[0m\n"
         << "Variable three: \e[38:2::102:51:153;48:2::255:240:245m" << three << "\e[0m\n" << endl;

    cout << "Test four: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> one; cout << "\e[0m\n"
         << "Test five: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> two; cout << "\e[0m\n"
         << "Test six: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> three; cout << "\e[0m"

         << "Variable four: \e[38:2::102:51:153;48:2::255:240:245m" << one << "\e[0m\n"
         << "Variable five: \e[38:2::102:51:153;48:2::255:240:245m" << two << "\e[0m\n"
         << "Variable six: \e[38:2::102:51:153;48:2::255:240:245m" << three << "\e[0m" << endl;

    return 0;
}

VS Code version: Code - Insiders 1.72.0-insider (2d27f8d, 2022-09-08T05:16:43.841Z)
OS version: Linux x64 5.17.0-1016-oem
Modes:
Sandboxed: Yes

vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30422396
pythontb:30258533
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805cf:30301675
bridge0708:30335490
bridge0723:30353136
cmake_vspar411cf:30557515
vsaa593:30376534
pythonvs932:30404738
cppdebug:30492333
vscaac:30438845
pylanb8912:30522163
vsclangdf:30492506
c4g48928:30535728
dsvsc012:30540252
pylantcb52:30558418
vscccc:30564267

Edit

So… Somehow, as I was writing this bug report, the issue seems to have almost completely gone away, except if I close VS Code and then reopen it. Maybe it has something to do with terminal sessions being restored somehow? I have screenshots of the issue occurring outside of the minimal test case earlier which I can share if need be, but, for now, I'll just share one screenshot of the test case. Note that the issue occurred in both test rounds (test one, two, three/test four, five, six) earlier.

Edit two

So, it seems that running clear before running the minimal test case makes the issue completely go away somehow. Bizarre.

Edit three

It seems like the same inconsistent behavior is shared by GNOME Terminal. I've just been putting the laptop to sleep instead of rebooting it for the past few days now, thinking that I might come across whatever is causing this unexpected inconsistency,

Edit four

Correcting a typo in the background segment of the ANSI code in the first test round (test one, two, three): 48::2:[RGB value] → 48:2::[RGB value]

Edit four

I'm still doing some testing on the method to recreate this after running clear — running the minimal test case several times in a row after running clear seems to do it, but I still need to get a grasp on exactly how many times and also do some more reproducibility testing — but here's a screenshot with the typo fix from above which is a better showcase of the issue. Software rendering seems to be affected as well, but to a much lesser extent, given that only the cursor is colored in and only in the first test round, test three to be specific.

Edit five

Here's a screen recording of the aforementioned minor issue with software rendering. I'm also renaming “Screenshots” to “Media” now.

Edit six

Running the script below, I've determined that the number of runs it takes before the issue appears after running clear is four in XTerm and XTerm.js and three in GNOME Terminal:

clear; declare -i i=0
while true; do
~/Projects/C++\ study/test
i=i+1
echo -e "\n\nRun number \e[91m"${i}"\e[0m\n\n"
done

Edit seven

OK… So… This is the weirdest thing I've ever seen. Just holding down Enter leads to reproducing the issue. Screen recording attached. Oh, also, it seems that the software rendering issue with the cursor outlined in edit four is definitely related to this issue, since holding down Enter for long enough when the terminal is set to software rendering yields a cursor with a colored-in background. Since there seems to be something causing both rendering modes to glitch out to various degrees, this ticket could probably use a new title. I can't think of one though 😅

Edit eight

So… After testing in all three terminals, it seems like the rendering goes haywire as soon as the terminal has to scroll because the number of lines held in memory exceeds the number of lines that can be displayed in a given window, at least when just holding Enter down. Screen recording attached.