A partial section of a terminal line is being shifted down one line

[sc0ttwad3]

Environment

Windows build number: Microsoft Windows [Version 10.0.18995.1]
Windows Terminal version: source git at: #aa682bfd (origin/master, origin/HEAD) doc: update the path to profiles.json (#3087) [Dustin L. Howett (MSFT)]

Any other software? Ubuntu-18.04_LTS WSL 2

Steps to reproduce

Simply open terminal, then open a new tab using the profile:

"commandline" : "wsl.exe -d Ubuntu-18.04"

Then run $ ls on a directory that has a lot of files (or any command such that the screen displays more then the number of lines your terminal is able show at one time. It may take more than one time, but usually after a couple.

Expected behavior

There should be normal display lines without the shifting of a section of the entry/cursor line down by one line; it should display correctly, like with prior builds.

Actual behavior

At some point, adding lines to the buffer after listing files (or anything else), starting from where the cursor is at, the current line gets shifted down by one line. Then near the end of the line, the remainder of the line is displayed correctly.

Any typing is displayed on the line down and is initially treated as valid input by your shell, but soon, the input line starts being displayed twice, or characters don't show up correctly, and generally becomes visually and functionally almost impossible to use.

I've also confirmed that is not related to any particular shell, commands, or programs. It's how Terminal's display handling of the line that appears to be the problem (no pun intended ;-).

Images attached show this more clearly. The first is simple file listing from zsh. The second is an example in Vim that shows exactly where the shift occurs. The cursor is on the line number that is underlined, but insert characters display on the next line. And the status bar provides clear range of the shift.

It's not .vimrc or any configuration issue in any program or dotfiles, none of those have changed, and vanilla vim and/or nvim show it clearly as well.

[sc0ttwad3]

Might this be related to other line problems such as the regression with line wrap mentioned in #2924 #3052

[DHowett-MSFT]

Yeah, this definitely looks like it could be #3052. Can you try after reverting 5d906d9?

[ghost]

This issue has been marked as duplicate and has not had any activity for 1 day. It will be closed for housekeeping purposes.