Scrolling within regions that include the top of the screen doesn't push lines into scrollback

[aananthcn]

Environment

Windows Terminal version: Version: 0.6.2951.0
Microsoft Windows [Version 10.0.18362.418]

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):

Any other software?

Steps to reproduce

1. Install Ubuntu 18.04 (on WSL 1.0), install minicom inside Ubuntu.
2. Open Windows Terminal and run Ubuntu 18.04
3. Open minicom from Windows Terminal and try to capture serial console message from any embedded dev. board (say Raspberry PI)
4. You will see messages scrolling above the view port. If you scroll up you won't see the messages from the minicom.

Expected behavior

If I scroll up, I should be able to see the serial console messages from my embedded target.

Actual behavior

Scroll up shows my command that I typed long ago. The serial console message is lost. If I run Ubuntu terminal directly (instead of doing the same from Windows Terminal), I could scroll up and see right messages.

Not sure, may be ncurses behavior is not compatible with Windows Terminal's expectations?

[j4james]

I think this is related to the scrolling margins. You'll see a similar problem when setting the scrolling margins to the first 10 lines of the screen with a bash command like this:

printf "\e[1;10r"

Then try doing a directory listing or output a lot of content that will cause the view to scroll. The scrolling will be limited to the top 10 lines, as expected, but anything that scrolls off the top of the screen is lost.

I think this is just a limitation of the current conpty implementation. It doesn't know anything about scrolling regions, so unless you're scrolling the full screen height, it won't update the scrollback buffer correctly.

[DHowett-MSFT]

We'll need to capture some VT from minicom to figure out exactly what it's doing here.

Would you be willing to run it under script to capture a transcript? Thanks!

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[vdoo-connected-trust-oper]

We'll need to capture some VT from minicom to figure out exactly what it's doing here.

Would you be willing to run it under script to capture a transcript? Thanks!

I'm experiencing the same issues.
Can you elaborate about running it under 'script' mode?

[DHowett-MSFT]

Sure! Check this out. If you run script, it will run another copy of your shell, but it will capture all the output that any program you run afterwards emits in raw form.

Here's the steps, roughly.

1. Run script
   • It will say something like Script started, file is typescript
2. You will get another copy of your shell.
3. Run minicom, and cause the incorrect scroll behavior.
4. Exit minicom.
5. Exit your shell (exit)
   • Script will say something like Script done, file is typescript
6. It made a file called "typescript"
7. Send us that file!

The file looks something like this:

All of those blue characters are the raw escape sequences that came out of my shell, and for you will be the ones coming out of minicom.

[meirtsvi]

Attached is a script file
typescript.zip

[DHowett-MSFT]

Thanks a lot! Just to make sure: I am seeing the bottom bar, which is red, duplicated multiple times on the screen. Is that the only issue?

If there's more issues than that, would you mind sharing a screenshot?

[DHowett-MSFT]

(If it's the bug where the scrollback is deleted, that's just how it's designed right now, unfortunately.)

[meirtsvi]

Yes, the red bottom bar is fine - no problem here. It's part of minicom when enabling color mode.
The problem is indeed with the scrollback - either it's not exist or when scrolling up I see commands I ran before invoking minicom

[DHowett-MSFT]

Ah! Thanks again for the test case. James's initial suspicion is right: there's a scrolling region, and we don't handle that great right now.

[zadjii-msft]

I'm re-opening this to track the scrolling margins + conpty issue, and tossing it on the backlog. Thanks!

[DHowett-MSFT]

I'll rename it to be something more scannable.

[ThomasHornschuh]

Hi, is there any plan to fix this issue soon?

[zadjii-msft]

@ThomasHornschuh Not particularly - it's being tracked as a part of our "Next Windows Release" milestone, but that doesn't really have any sort of timeline (certainly not one I can share publicly). Sorry about that!

[Jayce3032]

(If it's the bug where the scrollback is deleted, that's just how it's designed right now, unfortunately.)

It seems that I met the same issue, as below, the scroll bar seems be fixed length when i use cmd minicom,as right window.

[CoryC3K]

Just writing to say I found this post googling the same issue.

• In Windows terminal, SSH'd into a rPi, running minicom results in not being able to see previous output from minicom. If you scroll up it shows the bash command before minicom launched, but not the output from minicom.

• In Visual Studio Code Terminal, SSH'd into the same rPi, running minicom results in being able to scroll up and down like normal, and see the full history of minicom.

• In a vanilla windows command prompt (as well as powershell), SSH/rPi/minicom works as expected (you can mousewheel up to see previous minicom output).

It's only in Windows Terminal where it's all screwy and annoying. :(

Thanks for the hard work though guys! I'm a big fan of terminal!

[julee]

Any news for this issue?
Seems this bug cause minicom under wsl 1 cannot scroll up. Use vscode terminal to wsl, minicom can scroll up.
Seems Fluent Terminal has same problem.

[zadjii-msft]

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

This is also vaguely similar to #6056. I'm xlinking just in case, but I might be totally off base on that. Telnet doesn't actually use the margins, and I believe our theory with that one is that telnet.exe is actually running its own VT parser and using the Console API to scroll the buffer. But, that might be a similar enough scenario that doesn't work in ConPTY that we may want to come up with a universal solution to both.

[j4james]

FYI, I think I may have inadvertently fixed this issue while I was working on merging the LineFeed implementations into AdaptDispatch for issue #13408. It will probably be a while still before I have PR ready for that, and I'm not positive it'll fix this issue completely, but it looks promising so far.

[DHowett]

That's quite exciting! 😄