Skip to content

Escape sequences behave strangely over conpty when VirtualTerminalLevel is set #1965

@j4james

Description

@j4james

Environment

Windows build number: Version 10.0.18362.175
Windows Terminal version (if applicable): 0.2.1831.0

Steps to reproduce

  1. Set the HKCU\Console\VirtualTerminalLevel registry entry to 1, to enable support for VT escape sequences by default.

  2. Makes sure the initialCols option in the Windows Terminal profile is set to 120.

  3. Open a cmd shell in the Windows Terminal (this can't be a WSL bash shell - it must be something that would usually not have VT support enabled without the registry setting).

  4. Run the following Python script:

    import sys
    sys.stdout.write('X'*(120-10))
    sys.stdout.write('\033[1;34;47mHello\033[m\n')
    

Expected behavior

I'd expect this to display 110 X's followed by the word Hello, in blue on white, on the same line. This is what it looks like in a regular console cmd shell.

image

Actual behavior

What actually happens in the Windows Terminal is the Hello is displayed on the following line.

image

I don't have a good understanding of how the conpty stuff works, but my theory is that the escape sequences aren't actually being processed initially, and are just written out to the screen as literal characters. As a result the Hello is forced to wrap onto the next line, because there isn't enough space remaining. This screen structure is then passed through conpty somehow, at which point the escape sequences are processed and the text colors changed. But by that stage the wrapping has already taken effect, so the text is in the wrong place.

It's easier to see what's going on if you apply PR #1964 first. In that case, the ESC character gets translated to a ← when it isn't initially interpreted as an escape sequence. The other side of the conpty pipe then doesn't get a second chance to process those values as an escape sequence, so you just see the raw characters being written out.

image

This may be a good reason to reject PR #1964 for now, since it's clearly making the situation worse, but I think the real issue is in the conpty code, and if that were fixed then the PR might well be safe to merge.

Metadata

Metadata

Assignees

Labels

Area-ServerDown in the muck of API call servicing, interprocess communication, eventing, etc.Issue-BugIt either shouldn't be doing this or needs an investigation.Needs-Tag-FixDoesn't match tag requirementsProduct-ConptyFor console issues specifically related to conptyResolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions