ArgumentOutOfRangeException when snapping Windows Terminal from one screen to another screen's edge.

[carlossanlop]

Environment data

Windows 10
Using Windows Terminal (Preview) version 0.6.2951.0

Steps to reproduce or exception report

All the other similar issues have already been closed, which is why I'm opening a new one.

I have two screens, one in portrait mode, another one in landscape mode. I had the Windows Terminal window on the landscape mode, and I moved it to the portrait mode. I waited for Windows to snap the window automatically to the edges, and that's when the crash message showed up:

PS D:\corefx>
Oops, something went wrong.  Please report this bug with the details below.
Report on GitHub: https://github.com/PowerShell/PSReadLine/issues/new
### Environment
PSReadLine: 2.0.0-beta4
PowerShell: 7.0.0-preview.2
OS: Microsoft Windows 10.0.18363
Last 200 Keys
 Enter
 Enter
 Enter
 l s Enter
 g i t k Enter
 g i t Spacebar r e b a s e Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace g i t Spacebar r e b a s e Spacebar d o t n e t / m a s t e r Enter
 g i t k Enter
 c d Spacebar . . Enter
 c d Spacebar d o t n e t - a p i - d o c s Enter
 g i t Spacebar f e t c h Spacebar d o t n e t Enter
 c d Spacebar . . Enter
 c d Spacebar c o r e f x Enter
 g i t Spacebar s t a t u s Enter
 Enter

Exception

System.ArgumentOutOfRangeException: The value must be greater than or equal to zero and less than the console's buffer size in that dimension.
Parameter name: top
Actual value was 61.
   at System.ConsolePal.SetCursorPosition(Int32 left, Int32 top)
   at Microsoft.PowerShell.PSConsoleReadLine.AcceptLineImpl(Boolean validate)
   at Microsoft.PowerShell.PSConsoleReadLine.AcceptLine(Nullable`1 key, Object arg)
   at Microsoft.PowerShell.PSConsoleReadLine.ProcessOneKey(PSKeyInfo key, Dictionary`2 dispatchTable, Boolean ignoreIfNoAction, Object arg)
   at Microsoft.PowerShell.PSConsoleReadLine.InputLoop()
   at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics, CancellationToken cancellationToken)

I ran the script you suggest in the issue description template. Here is the output:

PS version: 7.0.0-preview.2
PSReadline version: 2.0.0-beta4
os: 10.0.18362.1 (WinBuild.160101.0800)
PS file version: 7.0.0.0
HostName: ConsoleHost (Windows Terminal)
BufferWidth: 151
BufferHeight: 56

[msftrncs]

Do you happen to have a command entered on the command line at the time this occurs? Did the window size change in the process? What was BufferWidth and BufferHeight before vs after?

Have you tried PSReadLine beta 5?

[carlossanlop]

@msftrncs
The first 3 questions are answered by the text I pasted:

• The last command I ran can be seen among the characters printed in the error thrown by PS: git status
• In my description, I moved the window from one screen to the other, then snapped it to the edge.
• The script template threw the buffer sizes 151 and 56. It's at the end of my message.
• I don't know what you mean by trying PSReadLine in beta 5.

[msftrncs]

@carlossanlop, you are using PSReadLine 2.0.0-beta4, beta5 is out, beta6 is coming soon.

However, looking at everything again (sorry, I must have been distracted), this looks like something I just posted a PR for, #1182, though its different that you ran in to it. Did you press ENTER after the screen snap event? Was the cursor on the screen at that time? Was there a different in DPI's between the two screens?

I'm trying to come up with the scenario to reproduce the issue. WindowsTerminal does seem to do some weird things when moving from a larger window to a smaller one ...

[msftrncs]

Okay, think I found it.

1. Start with a normal terminal window.
2. Move it to a large screen and snap it to a vertical edge to make the window long (tall).
3. run some commands, so the buffer is full.
4. type a command, but do not enter it yet.
5. undock it from the edge so it reverts to a regular window.
6. press enter

It seems to help that the cursor is further down the buffer while the window is larger, than there is lines in the buffer when the window is smaller, with the command already typed out before the window is moved.

There is another issue, if you undock back to the smaller window, then dock again to a bigger window, the text will be scrolled up but the cursor will move back to the bottom on the next keypress.

I think PR #1182 takes care of this exception issue, from what I can test.