starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Odd terminal scrolling behaviour #14117

New Issue
Closed
opened 2026-01-31 04:01:21 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 04:01:21 +00:00
Owner
Copy Link

Originally created by @SetTrend on GitHub (Jun 4, 2021).

Originally assigned to: @zadjii-msft on GitHub.

Issue Description

I am experiencing a problem with the terminal scrolling behaviour when switching from side panel view to full panel view in Visual Studio Code:

Strange scrolling behaviour

/ref: vscode-powershell#3344
/ref: PSReadLine#2450
/ref: vscode#125434

PS: This is the fourth address I'm addressing this issue to. Hope to address the right repository team this time.

Expected Behaviour

When I hit the ARROW UP key, I would expect to see different versions of my execution history, but I don't expect a scrolling behaviour.

Actual Behaviour

When I hit the ARROW UP key after having switched the PowerShell terminal from side panel to full panel, scrolling is performed that's mimicking the previous side panel layout.

Originally created by @SetTrend on GitHub (Jun 4, 2021). Originally assigned to: @zadjii-msft on GitHub. ### Issue Description I am experiencing a problem with the terminal scrolling behaviour when switching from side panel view to full panel view in Visual Studio Code: ![Strange scrolling behaviour](https://user-images.githubusercontent.com/9283914/117493211-f8309c80-af72-11eb-8db7-365aae3850e9.gif) /ref: [vscode-powershell#3344](/PowerShell/vscode-powershell/issues/3344) /ref: [PSReadLine#2450](/PowerShell/PSReadLine/issues/2450) /ref: [vscode#125434](/microsoft/vscode/issues/125434) PS: This is the fourth address I'm addressing this issue to. Hope to address the right repository team this time. #### Expected Behaviour When I hit the `ARROW UP` key, I would expect to see different versions of my execution history, but I don't expect a scrolling behaviour. #### Actual Behaviour When I hit the `ARROW UP` key after having switched the PowerShell terminal from side panel to full panel, scrolling is performed that's mimicking the previous side panel layout.
claunia commented 2026-01-31 04:01:23 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 4, 2021):

Ah, so you've landed on the right issue tracker! Sorry you've been redirected so many times.

This is one of the things we don't do very well, and it is a very longstanding bug in how the console has worked since Windows 10.0.10240 (the first public release). It all goes back to "resize with reflow" and how, on a ~ ~ normal ~ ~ Windows console, there's about 9001 lines of empty space below the screen.

When we resize to a taller size, we haven't historically locked the bottom of the viewport to the bottom of the new buffer. It may not even be possible in some cases (like: there are only 5 lines in the scrollback but you need to extend to a 100-line-tall window.) So--when we need to expose more lines, we adjust the "virtual bottom" of the screen. We move the bottom down to expose some of those thousands of empty lines.

Now this means that for VSCode (after the advent of ConPTY) and Windows Terminal and the inimitable @wez's wezterm, the display actually does contain those lines¹. When the terminal emulator tries to snap the viewport back to the visible region (as some do on input, and some do on output, and some let you configure), it scrolls those blank lines back into view.

¹ It is part of how we keep up the illusion that this is a terminal, not a weird crufty Windows console

@DHowett commented on GitHub (Jun 4, 2021): Ah, so you've landed on the right issue tracker! Sorry you've been redirected so many times. This is one of the things we don't do very well, and it is a very longstanding bug in how the console has worked since Windows 10.0.10240 (the first public release). It all goes back to "resize with reflow" and how, on a ~ ~ normal ~ ~ Windows console, there's about 9001 lines of empty space _below the screen_. When we resize to a taller size, we haven't historically locked the bottom of the viewport to the bottom of the new buffer. It may not even be possible in some cases (like: there are only 5 lines in the scrollback but you need to extend to a 100-line-tall window.) So--when we need to expose more lines, we adjust the "virtual bottom" of the screen. We move the bottom down to expose some of those thousands of empty lines. Now this means that for VSCode (after the advent of ConPTY) and Windows Terminal and the inimitable @wez's wezterm, _the display actually does contain those lines¹_. When the terminal emulator tries to snap the viewport back to the visible region (as some do on input, and some do on output, and some let you configure), it scrolls those blank lines back into view. ¹ It is part of how we keep up the illusion that this is a terminal, not a weird crufty Windows console
claunia commented 2026-01-31 04:01:23 +00:00
Author
Owner
Copy Link

@SetTrend commented on GitHub (Jun 4, 2021):

Thank you for taking the time with this issue and for your very informative answer!

Hmm ... do you think there's a remedy in sight to cope with this? You know, it's hard to type new commands based on results from previous commands if you can't read those previous results.

@SetTrend commented on GitHub (Jun 4, 2021): Thank you for taking the time with this issue and for your very informative answer! Hmm ... do you think there's a remedy in sight to cope with this? You know, it's hard to type new commands based on results from previous commands if you can't read those previous results.
claunia commented 2026-01-31 04:01:24 +00:00
Author
Owner
Copy Link

@wez commented on GitHub (Jun 4, 2021):

I don' t know if this helps you (as a vscode user, rather than the owner of the vscode terminal bits), but wezterm has logic to try to make this behave more nicely:
https://github.com/wez/wezterm/blob/main/term/src/config.rs#L44-L70
https://github.com/wez/wezterm/blob/main/term/src/screen.rs#L220-L237

@wez commented on GitHub (Jun 4, 2021): I don' t know if this helps you (as a vscode user, rather than the owner of the vscode terminal bits), but wezterm has logic to try to make this behave more nicely: https://github.com/wez/wezterm/blob/main/term/src/config.rs#L44-L70 https://github.com/wez/wezterm/blob/main/term/src/screen.rs#L220-L237
claunia commented 2026-01-31 04:01:24 +00:00
Author
Owner
Copy Link

@SetTrend commented on GitHub (Jun 25, 2021):

Are there any changes to get things fixed anytime soon?

There's not a single Windows PowerShell implementation not suffering from this.

Here's Visual Studio 2019:

PSReadLine bug

@SetTrend commented on GitHub (Jun 25, 2021): Are there any changes to get things fixed anytime soon? There's not a single Windows PowerShell implementation not suffering from this. Here's Visual Studio 2019: ![PSReadLine bug](https://user-images.githubusercontent.com/9283914/123458157-03a05b80-d5e5-11eb-8360-53d93805af6d.gif)
claunia commented 2026-01-31 04:01:24 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 7, 2021):

@SetTrend that most recent gif actually looks like a totally different issue with the WPFTerminalControl - the text certainly shouldn't be overwriting like that. I'm gonna move that to another thread, to address specifically.

I'm not sure there is a good solution unfortunately. Conpty does make it hard to address this, but that's the only way to maintain the illusion that we're not actually a console (even though we are). Maybe we could not snap on input/output when the cursor is still in the visible viewport?

okay wait I actually like that. The lines would still always be there, but the viewport wouldn't move.

This would change the spec

 By default, the viewport will scroll to new output if the following conditions are met:
 - no selection is active
-- the viewport is at the "virtual bottom" (the bottom of the scroll history)
+- the visible viewport contains the cursor. (this is always true when the visible viewport is at the "virtual bottom" (the bottom of the scroll history))

@carlos-zamora for thoughts

@zadjii-msft commented on GitHub (Jul 7, 2021): @SetTrend that most recent gif actually looks like a totally different issue with the WPFTerminalControl - the text certainly shouldn't be overwriting like that. I'm gonna move that to another thread, to address specifically. <hr> I'm not sure there is a good solution unfortunately. Conpty does make it hard to address this, but that's the only way to maintain the illusion that we're not actually a console (even though we are). Maybe we could not snap on input/output when the cursor is still in the visible viewport? okay wait I actually like that. The lines would still always _be there_, but the viewport wouldn't move. This would change [the spec](https://github.com/microsoft/terminal/blob/main/doc/specs/%23980%20-%20SnapOnOutput.md) ```diff By default, the viewport will scroll to new output if the following conditions are met: - no selection is active -- the viewport is at the "virtual bottom" (the bottom of the scroll history) +- the visible viewport contains the cursor. (this is always true when the visible viewport is at the "virtual bottom" (the bottom of the scroll history)) ``` @carlos-zamora for thoughts
claunia commented 2026-01-31 04:01:24 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 15, 2021):

Wait hold up. You can already fix this in the Terminal with simply "snapOnInput": false in a profile, or in profiles.defaults. The other aforementioned scrolling behavior only applies when there are new lines emitted to the Terminal, which would trigger scrolling with this behavior anyways (since they are by definition not going to be in the visible viewport).

You can see the delta in https://github.com/microsoft/terminal/compare/dev/migrie/b/10332-less-snappy-scrolling. It's simply not a relevant change, once snapOnInput:false is set.

Unfortunately, I'm not seeing any sort of similar setting in VsCode itself. That might be valuable feedback to take back to them.

As far as the number of lines emitted by conpty during a resize - I'm afraid there's nothing that can be done about that. The conpty console buffer needs to be able to have something there, even if that something is nothing, and it it needs the connected terminal to know that those lines are there as well. Plenty of research was done into alternative solutions, see #4200 and all the linked issues for that saga.

@zadjii-msft commented on GitHub (Jul 15, 2021): Wait hold up. You can already fix this in the Terminal with simply `"snapOnInput": false` in a profile, or in `profiles.defaults`. The other aforementioned scrolling behavior only applies when there are new lines emitted to the Terminal, which would trigger scrolling with this behavior anyways (since they are by definition not going to be in the visible viewport). You can see the delta in https://github.com/microsoft/terminal/compare/dev/migrie/b/10332-less-snappy-scrolling. It's simply not a relevant change, once `snapOnInput:false` is set. Unfortunately, I'm not seeing any sort of similar setting in VsCode itself. That might be valuable feedback to take back to them. As far as the number of lines emitted by conpty during a resize - I'm afraid there's nothing that can be done about that. The conpty console buffer needs to be able to have _something_ there, even if that something is _nothing_, and it it needs the connected terminal to know that those lines are there as well. Plenty of research was done into alternative solutions, see #4200 and all the linked issues for that saga.
claunia commented 2026-01-31 04:01:25 +00:00
Author
Owner
Copy Link

@SetTrend commented on GitHub (Jul 15, 2021):

@zadjii-msft:

Thank you for your valuable comment.

Which of the repositories linked to in this thread at the top would you suggest to report your findings to?

@SetTrend commented on GitHub (Jul 15, 2021): @zadjii-msft: Thank you for your valuable comment. Which of the repositories linked to in this thread at the top would you suggest to report your findings to?
claunia commented 2026-01-31 04:01:25 +00:00
Author
Owner
Copy Link

@mailinglists35 commented on GitHub (Sep 13, 2023):

@ everyone sorry for offtopic - @SetTrend what tool did you use to dynamically zoom in / out while capturing the screen recording?

@mailinglists35 commented on GitHub (Sep 13, 2023): @ everyone sorry for offtopic - @SetTrend what tool did you use to dynamically zoom in / out while capturing the screen recording?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-TerminalControl Issue-Question Product-Terminal Resolution-Answered
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#14117
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?