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

Closed
opened 2026-01-31 00:05:52 +00:00 by claunia · 24 comments
Owner

Originally created by @aananthcn on GitHub (Nov 23, 2019).

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?

Originally created by @aananthcn on GitHub (Nov 23, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment Windows Terminal version: Version: 0.6.2951.0 Microsoft Windows [Version 10.0.18362.418] ```none 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. <!-- A description of how to trigger this bug. --> # Expected behavior If I scroll up, I should be able to see the serial console messages from my embedded target. <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # 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. <!-- What's actually happening? --> Not sure, may be ncurses behavior is not compatible with Windows Terminal's expectations?
claunia added the Issue-BugIn-PRArea-VTNeeds-Tag-FixProduct-ConptyPriority-2 labels 2026-01-31 00:05:53 +00:00
Author
Owner

@j4james commented on GitHub (Nov 23, 2019):

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.

@j4james commented on GitHub (Nov 23, 2019): 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.
Author
Owner

@DHowett-MSFT commented on GitHub (Nov 25, 2019):

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!

@DHowett-MSFT commented on GitHub (Nov 25, 2019): 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!
Author
Owner

@ghost commented on GitHub (Nov 29, 2019):

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.

@ghost commented on GitHub (Nov 29, 2019): 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**.
Author
Owner

@vdoo-connected-trust-oper commented on GitHub (Apr 2, 2020):

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?

@vdoo-connected-trust-oper commented on GitHub (Apr 2, 2020): > 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?
Author
Owner

@DHowett-MSFT commented on GitHub (Apr 3, 2020):

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:

image

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.

@DHowett-MSFT commented on GitHub (Apr 3, 2020): 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: ![image](https://user-images.githubusercontent.com/14316954/78313575-08727e80-750c-11ea-8a47-e0bb2505749e.png) 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.
Author
Owner

@meirtsvi commented on GitHub (Apr 3, 2020):

Attached is a script file
typescript.zip

@meirtsvi commented on GitHub (Apr 3, 2020): Attached is a script file [typescript.zip](https://github.com/microsoft/terminal/files/4425658/typescript.zip)
Author
Owner

@DHowett-MSFT commented on GitHub (Apr 3, 2020):

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 commented on GitHub (Apr 3, 2020): 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?
Author
Owner

@DHowett-MSFT commented on GitHub (Apr 3, 2020):

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

@DHowett-MSFT commented on GitHub (Apr 3, 2020): (If it's the bug where the scrollback is deleted, that's just how it's designed right now, unfortunately.)
Author
Owner

@meirtsvi commented on GitHub (Apr 3, 2020):

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

@meirtsvi commented on GitHub (Apr 3, 2020): 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
Author
Owner

@DHowett-MSFT commented on GitHub (Apr 3, 2020):

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.

@DHowett-MSFT commented on GitHub (Apr 3, 2020): 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.
Author
Owner

@zadjii-msft commented on GitHub (Apr 3, 2020):

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

@zadjii-msft commented on GitHub (Apr 3, 2020): I'm re-opening this to track the scrolling margins + conpty issue, and tossing it on the backlog. Thanks!
Author
Owner

@DHowett-MSFT commented on GitHub (Apr 3, 2020):

I'll rename it to be something more scannable.

@DHowett-MSFT commented on GitHub (Apr 3, 2020): I'll rename it to be something more scannable.
Author
Owner

@ThomasHornschuh commented on GitHub (Nov 26, 2020):

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

@ThomasHornschuh commented on GitHub (Nov 26, 2020): Hi, is there any plan to fix this issue soon?
Author
Owner

@zadjii-msft commented on GitHub (Dec 1, 2020):

@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!

@zadjii-msft commented on GitHub (Dec 1, 2020): @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!
Author
Owner

@Jayce3032 commented on GitHub (Dec 4, 2020):

(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.
image

@Jayce3032 commented on GitHub (Dec 4, 2020): > (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. ![image](https://user-images.githubusercontent.com/48389490/101118105-69b29a80-3623-11eb-9c78-5ebdf9782ebc.png)
Author
Owner

@CoryC3K commented on GitHub (Oct 13, 2021):

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!

@CoryC3K commented on GitHub (Oct 13, 2021): 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!
Author
Owner

@julee commented on GitHub (Mar 19, 2022):

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.

@julee commented on GitHub (Mar 19, 2022): 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.
Author
Owner

@zadjii-msft commented on GitHub (Mar 21, 2022):

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
image
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.

@zadjii-msft commented on GitHub (Mar 21, 2022): Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) 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.
Author
Owner

@j4james commented on GitHub (Feb 7, 2023):

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.

@j4james commented on GitHub (Feb 7, 2023): 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.
Author
Owner

@DHowett commented on GitHub (Feb 7, 2023):

That's quite exciting! 😄

@DHowett commented on GitHub (Feb 7, 2023): That's quite exciting! :smile:
Author
Owner

@ClaireCJS commented on GitHub (Nov 6, 2024):

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.)

@ClaireCJS commented on GitHub (Nov 6, 2024): > FYI, I think I may have inadvertently fixed this issue while I was working on merging the `LineFeed` implementations into `AdaptDispatch` for issue [#13408](https://github.com/microsoft/terminal/issues/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.)
Author
Owner

@j4james commented on GitHub (Nov 6, 2024):

@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.

@j4james commented on GitHub (Nov 6, 2024): @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.
Author
Owner

@ClaireCJS commented on GitHub (Nov 7, 2024):

@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:
Image

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

@ClaireCJS commented on GitHub (Nov 7, 2024): > [@ClaireCJS](https://github.com/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: ![Image](https://github.com/user-attachments/assets/7efde633-e02e-4aa7-95c5-456b64f7bbb6) Is that even possible at the bottom, or am I restricted to just 1 line, not 3 like i used here?
Author
Owner

@j4james commented on GitHub (Nov 7, 2024):

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.

@j4james commented on GitHub (Nov 7, 2024): > 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](https://github.com/microsoft/terminal/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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5135