Certain ANSI sequences can cause integrated terminal to start showing bold text when it shouldn't

[CherryDT]

Windows 10, Build 15036

Version 1.14.0-insider
Commit 779a7df
Date 2017-06-23T05:59:57.891Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0

Something weird happens for me for quite some time now. It is that after certain output, all text starts to be bold in the integrated terminal, usually until some process is closed or in case of SSH until the session is closed. But it still may have some kind of "buggy state" afterwards, see below.

Test case 1

1. Run WSL bash in integrated terminal
2. Open node (v8.0.0) REPL
3. Enter 12345 and press Enter. Everything is still okay, nothing is bold.
4. Enter null and press Enter. Note that the output word null is bold.
5. Enter 12345 and press Enter. Note that what you enter is now also bold (but the yellow text is not).
6. Exit by pressing Ctrl+C twice. Note that the output about having to press Ctrl+C twice is also bold.
7. Repeat the above steps 2-6 once more. Note that the problem has been resolved by quitting node, it will again work normally until step 4 is reached.

Test case 2

Interestingly, this case behaves slightly different from test case 1 and shows that there is some kind of state which is not fully reset when existing the process which caused the bold text in the first place.

1. Run Git bash in integrated terminal.
2. Same as above: Open node (v8.0.0) REPL
3. Same as above: Enter 12345 and press Enter. Everything is still okay, nothing is bold.
4. Same as above: Enter null and press Enter. Note that the output word null is bold.
5. Same as above: Enter 12345 and press Enter. Note that what you enter is now also bold (but the yellow text is not).
6. Same as above: Exit by pressing Ctrl+C twice. Note that the output about having to press Ctrl+C twice is also bold.
7. Repeat steps 2-6 once more. You will notice that, unlike in test case 1, there is a subtle difference in the second iteration: In step 4, when you start typing null, the text you type is already bold. This is different from case 1, in which only the formatting of the output null triggered the bold text - now, also the yellow number output triggers the bold text, if the bug already has been triggered once before in the same shell session!

I used script on a real linux machine (it's not working in WSL yet) to record the output of scenario 1 into a text file, see attachment. When cating that file, it causes exactly the same issue as in scenario 1. However, even when doing that in Git bash, it behaves as in scenario 1, not scenario 2.
nodetest2.txt

These are the relevant escape sequences from the file:

[zerocrates]

I have a $PS1 that turns bold on and off a couple times, and the integrated terminal gets it exactly backwards: the parts that should be bold are normal weight, the parts that should be normal are bold, and all "normal" text after the prompt is stuck on bold. (Of course, it works correctly on "real" terminals.)

Even an extremely pared-down sequence, just setting bold and resetting to normal, fails: the final "not bold" and all further text is bolded:

echo -e "not bold, \e[1mbold,\e[0m not bold"

Interestingly, if instead the "middle" section sets a color, the color applies and is removed correctly, but the end text and all further text is still bolded, even though there was no bold sequence emitted at all: (run in a "fresh" terminal, of course)

echo -e "normal, \e[32mcolor,\e[0m normal"

This is what accounts for the "backwards" behavior I see for my PS1, since the bolded sections also set a color.

Is this an xterm-js problem, or is it getting fed bogus input? After the initial command, InputHandler.prototype.charAttributes gets called for every character typed, with seemingly bogus params of [0,1]

[Tyriar]

@zerocrates all this sort of stuff is handled within xterm.js, trying to repro on the demo in https://github.com/sourcelair/xterm.js would be useful.

[latkin]

Seeing possibly the same issue. Simple repro with powershell, note that "White" ConsoleColor causes bold text to be used.

Windows 10
Version 1.16.0
Commit 787b31c0474e6165390b5a5989c9619e3e16f953
Date 2017-09-06T16:27:49.891Z
Shell 1.7.3
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

[Tyriar]

This is likely related to winpty, tracking in #45693