Odd terminal scrolling behaviour

[SetTrend]

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:

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

[DHowett]

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

[SetTrend]

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.

[wez]

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

[SetTrend]

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:

[zadjii-msft]

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

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.

[SetTrend]

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

[mailinglists35]

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