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!

[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! 😄

[ClaireCJS]

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.

Hi... It doesn't seem to have happened? I head the idea to make headers on some scripts only to find out that doing so made me lose all the output in the scrollback. (Alternate buffer isn't what I want either.)

[j4james]

@ClaireCJS It sounds like you're trying to set a scroll region starting from line 2, e.g. if your screen height is 24, I'm guessing you're setting the scroll region to something like \e[2;24r so that line 1 remains fixed. But that's not expected to push lines into the scrollback - anything that scrolls off the top of that region will be lost.

The scenario we were trying to fix here was a scroll region like \e[1;23r, where row 24 is fixed (typically used for something like a status bar). In that case the top part of the screen is expected to push lines into the scrollback. This can only work when the first parameter of the DECSTBM sequence is 1.

[ClaireCJS]

@ClaireCJS It sounds like you're trying to set a scroll region starting from line 2, e.g. if your screen height is 24, I'm guessing you're setting the scroll region to something like \e[2;24r so that line 1 remains fixed. But that's not expected to push lines into the scrollback - anything that scrolls off the top of that region will be lost.

The scenario we were trying to fix here was a scroll region like \e[1;23r, where row 24 is fixed (typically used for something like a status bar). In that case the top part of the screen is expected to push lines into the scrollback. This can only work when the first parameter of the DECSTBM sequence is 1.

You did ascertain correctly what I was doing.

So there's just no way to do that? To me, everything should just scroll past the locked part.

This kinda destroys my concept of having headers at the top describing what is being done. Of course the tab title exists but that's not nearly as pretty (wish i could change its color to indicate status).

Though if i'm hearing you right — the idea would work at the BOTTOM of the screen, but ONLy with the last row, not with any more rows?

Basically, i just wanted to make a pretty 3 (or 4) line header at top saying what was happening, that looks like this:

Is that even possible at the bottom, or am I restricted to just 1 line, not 3 like i used here?

[j4james]

To me, everything should just scroll past the locked part.

@ClaireCJS I'm afraid that's not how margins work. You might be able to achieve something like that manually, if you're controlling the scrolling yourself, but you wouldn't be able to run a random application or shell within the margin area and just expect it to work.

If you want more info on how that could be achieved, it would probably be best to continue this conversation in the discussions area. I think we've strayed quite far off topic here.

the idea would work at the BOTTOM of the screen, but ONLy with the last row, not with any more rows?

You can lock as many rows as you want at the bottom of the screen. The only requirement is that the first row of the margin area is at the top of the screen, i.e. there can be no gap between the area you are scrolling and the scrollback buffer if you want the content to be pushed into the scrollback.