terminal: Bug: resizing doesn't work properly in Windows Terminal

Environment

Windows build number: [Version 10.0.18362.175]
Windows Terminal version (0.2.1715.0):

Steps to reproduce

open any terminal (PowerShell/cmd/wsl). type any command (e.g. dir, ver, uname) and enter. resize the app window to the minimum and gradually enlarge the window.

Expected behavior

information should stay the same. shouldn’t break and should render all the characters like below

powershell0 wsl0 cmd0

Actual behavior

breaks apart and doesn’t render properly

powershell1 wsl1 cmd1

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 16
Comments: 16 (10 by maintainers)

Commits related to this issue

Cleanup for review - this is a _great_ fix for #3490 as well as #1465 — committed to microsoft/terminal by zadjii-msft 4 years ago
Add support for "reflow"ing the Terminal buffer (#4741) This PR adds support for "Resize with Reflow" to the Terminal. In conhost, `ResizeWithReflow` is the function that's responsible for reflowin... — committed to microsoft/terminal by zadjii-msft 4 years ago

Most upvoted comments

If I set "historySize" : 90000, resizing will be broken vs "historySize" : 9000, it will work fine. Version: 0.5.2762.0

+10

jjoos on Oct 6, 2019

If I set "historySize" : 90000, resizing will be broken vs "historySize" : 9000, it will work fine. Version: 0.5.2762.0

It seems that the historySize limit seems 32K - possible_screen_rows. So if your terminal can have 120 lines at most, historySize should be 32648 or less. So practically, the value around 32600 can be good enough; 9999 is too small for me anyway.

espresso3389 on Dec 16, 2019

(I should have added that I was testing with master a5f31f77 .

OpenConsole in debug or in release?

OK the slowness was just in debug mode; I recompiled and re-tested in release mode and it’s back to the usual speed (“fast”).

If vtpipeterm is hitting it too, that’s definitely a conpty issue.

For this my interpretation of what’s going on may be erroneous because I’m also looking at the background host window, while the front window only allows resizing but not scrolling. See the animation below. 2019-06-24_19-36-51

HBelusca on Jun 24, 2019

Another repro from another thread:

Steps to reproduce

SSH to a linux. I tired centos7.

Maximize the windows terminal window.

Enter a command which print something to the terminal. for example “ls”.

Restore down the window.

keep pressing enter to create new lines.

Expected behavior

Nothing happens.

Actual behavior

Previous message is shown again.

zadjii-msft on Nov 21, 2019

I think I found one resize bug. A ConPTY sends two WINDOW_BUFFER_SIZE_EVENT messages when the window is restored from maximize, but the first one has the wrong size (not sure of the internals of this, but it appears in conhost/tmux/pwsh, alacritty/pwsh, and Windows Terminal).

Run this program as conevents -es in conhost and a different terminal to see the difference; maximize and restore the window. For example, restoring the WinTerm window reports 119 x 46 in the WINDOW_BUFFER_SIZE_EVENT message, but GetConsoleScreenBufferInfo returns the correct value 119 x 32.

parkovski on Jun 29, 2019