Repository navigation
Copying and pasting a comment raised an exception, until I ran Clear-Host #1081
Description
Backtrace
Oops, something went wrong. Please report this bug with the details below.
Report on GitHub: https://github.com/PowerShell/PSReadLine/issues/newEnvironment
PSReadLine: 2.0.0-beta4
PowerShell: 7.0.0-preview.3
OS: Microsoft Windows 10.0.18362
Last 200 Keys
A s s i g n Spacebar a l e r t s @ C L I E N T D O M A I N Spacebar t o Spacebar t h i s . Enter
Ctrl+Enter ( G e t - A c c e p t e d D o m a i n Spacebar | Spacebar S e l e c t Spacebar - E x p a n d P r o p e r t y Spacebar D o m a i n N a m e ) Spacebar | Spacebar F o r E a c h - O b j e c t Spacebar { Enter
Ctrl+Enter Spacebar Spacebar Spacebar Spacebar S e t - M a i l C o n t a c t Spacebar " a l e r t s " Spacebar - E m a i l A d d r e s s e s Spacebar @ { A d d = " a l e r t s @ $ _ " } Spacebar - E r r o r A c t i o n Spacebar S t o p Enter
Ctrl+Enter } Enter
Ctrl+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 'top')
Actual value was 63.
at System.ConsolePal.SetCursorPosition(Int32 left, Int32 top)
at Microsoft.PowerShell.PSConsoleReadLine.MoveCursor(Int32 newCursor)
at Microsoft.PowerShell.PSConsoleReadLine.MoveToLine(Int32 numericArg)
at Microsoft.PowerShell.PSConsoleReadLine.PreviousLine(Nullable`1 key, Object arg)
at Microsoft.PowerShell.PSConsoleReadLine.InsertLineAbove(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)
Environment data
PS version: 7.0.0-preview.3
PSReadline version: 2.0.0-beta4
os: 10.0.18362.1 (WinBuild.160101.0800)
PS file version: 7.0.0.0
BufferWidth: 254
BufferHeight: 63Steps to reproduce or exception report
Get a nice, full scrollback buffer. Then, paste the text ### Assign alerts@CLIENTDOMAIN to this. into PowerShell 7.0.0-preview3. This one block of code always causes the same problem:
### Assign alerts@CLIENTDOMAIN to this.
(Get-AcceptedDomain | Select -ExpandProperty DomainName) | ForEach-Object {
Set-MailContact "alerts" -EmailAddresses @{Add="alerts@$_"} -ErrorAction Stop
}There are some more lines of code before that that all ran fine. However, that comment line caused PSReadLine to fail. The code afterwards ran just fine.
Weirdly enough, after running Clear-Host, everything appeared to be fine. I could paste that in all day.
This might (or might not) be a bug in Windows Terminal. It appeared to work fine when I opened PowerShell 7 with pwsh-preview.
Activity
msftrncs commentedon Oct 2, 2019
Colin Cogle (@rhymeswithmogul), I have experienced some very weird behavior when pasting in Windows Terminal, but my first suggestion is that you should update to PSReadLine 2.0.0-beta5 from PowerShellGallery, and then see if issues still occur.
Of interesting note here, is that the 'actual value' was equal to the buffer size, and not negative, which has been the normal error in the past.
rhymeswithmogul commentedon Oct 2, 2019
Nope, the same behavior occurs under 2.0.0-beta5.
msftrncs commentedon Oct 2, 2019
I seem to be getting the same error if I paste using the right click (sometimes) things that causes the window to scroll off the bottom. This is in addition to weird behavior such as additional blank lines being inserted, including below the final prompt.
What I pasted was:
Problem doesn't seem to happen if using CTRL-V.
msftrncs commentedon Oct 2, 2019
I am leaning on this being a Windows Terminal issue...
rhymeswithmogul commentedon Oct 2, 2019
That's what I'm thinking now, too. Right-clicking to paste into
pwsh-previewworks fine, as does pasting with Control-V in Windows Terminal like you found out.It's only when you right-click to paste into Windows Terminal and it scrolls the screen that the error occurs. When it happens, you also see extra (or the wrong kind of?) line breaks on the screen, which show up as
Enter Ctrl+Enterin the backtrace.I don't think there's anything PSReadLine can do to work around this, or inform the user that this is a known issue. Hopefully Microsoft fixes it on their end.
nickdurcholz commentedon Oct 8, 2019
I ran into this as well. Has anyone filed an issue with https://github.com/microsoft/terminal ? I searched for PSReadLine and ArgumentOutOfRange exception, but didn't find anything...
msftrncs commentedon Oct 9, 2019
I have posted an issue there, but I think there might be some bugs in PSReadline that could use to be solved. In this case, the exception is occurring because PSReadline is attempting for 'render' past the bottom of the screen.
This exception can be easily reproduced in such terminals, by just pressing CTRL-ENTER or CTRL-J until the new lines extend to the bottom of the terminal,
msftrncs commentedon Oct 11, 2019
This is being tracked as microsoft/terminal#1091.
msftrncs commentedon Oct 16, 2019
I am able to reproduce the exception report in VS Code using the method I outlined above. In VS Code, I disabled the default CTRL-J keybinding so it could be exposed to the terminal, which then sends a CTRL-ENTER combination instead, and when the cursor flows off the top of the screen, the exception is reported. Its too bad both VS Code and Windows Terminal send CTRL-ENTER in place of CTRL-J.
msftrncs commentedon Oct 17, 2019
Note, the lines below the cursor must be empty, if they are not, it will just beep when the buffer becomes full.
msftrncs commentedon Oct 20, 2019
I think I have determined the conditions for the reproduction to be more consistent. The cursor must be on the prompt line, or the first line after the prompt, with the buffer (screen) already full of lines, so that the prompt line is at the top. Using CTRL-ENTER (CTRL-J in Windows Terminal or VS Code Terminal), the first time you get a beep, and the prompt line disappears, and the second time the ArgumentOutOfRangeException occurs. If the cursor is anywhere else, no exception. The content on the buffer doesn't seem to matter.
Also, another quirk potentially related to this, is that if the cursor is in the second line of the buffer, when CTRL-ENTER occurs, the cursor is moved to the first line (prompt line). That's exactly where the cursor is when the exception occurs, its on the second line because the prompt scrolled off the top.
Don't SetCursorPosition when not Rendered.
msftrncs commentedon Nov 1, 2019
While the behavior from Windows Terminal is not ideal, it seems to be exposing an issue in how PSReadLine handles input and then renders it. I've been trying to debug what specifically is causing the exception reports that occur while pasting in Windows Terminal (the one shown in the OP is the same as what I get).
Because rendering is delayed when there is a queue of input waiting to be processed, but yet
SetCursorPosition()occurs (fromMoveCursor()) immediately when any key is processed that intentionally moves the cursor,_initialYis not in sync with where the buffer will be, the calculated cursor position risks being off the screen (in this case, beyond the buffer, causing the exception seen).SteveL-MSFT commentedon Nov 7, 2019
Carl Morris (@msftrncs) can you dump
$Host.UI.RawUIso I can see how big your window is and try to repro?msftrncs commentedon Nov 7, 2019
Reproduction is kind of tricky, because its dependent on timing, Smaller windows recreate the problem faster, along with short lines in the pasted code.
The pasted code is more likely to produce the reported exception (Top > BufferHeight, issue in MoveCursor), if there are a bunch of short lines, and you are already at the bottom of the terminal. Some things that help is having a fast system that isn't doing much in the background. The faster the paste operation occurs in Windows Terminal, the more likely the exception occurs.
My $Host.UI.RawUI
Test Script
1 remaining item
SteveL-MSFT commentedon Nov 7, 2019
Ok, can easily repro in VSCode with Ctrl+J (after removing default key binding). Haven't been able to repro in Windows Terminal, but will see about fixing it in VSCode and hopefully that fixes it elsewhere.
msftrncs commentedon Nov 7, 2019
Is Windows Terminal inserting the CTRL-ENTER when pasting? To get the specific exception report in the OP, that's the secret. I understand they just merged the fix for the CTRL-ENTER pasting issue in Windows Terminal yesterday.
SteveL-MSFT commentedon Nov 7, 2019
Carl Morris (@msftrncs) I don't think the original issue is the same as what you are reporting with Ctrl+J. Ctrl+J definitely has an issue as in Windows mode, it will attempt to insert a new line above the current cursor. However, it's not positioning the cursor correctly. This seems to be an easy fix. The pasting of a buffer is something else which I can't repro yet.
SteveL-MSFT commentedon Nov 7, 2019
Carl Morris (@msftrncs) while debugging a different issue, what I observed on Windows is that if you paste multiline content into PowerShell. The line ending is
\r\nwhich is expected for Windows. PSReadLine however sees this as two key presses, the first\ris just a Enter while\nthat follows is mapped to Ctrl+Entermsftrncs commentedon Nov 7, 2019
The observation about
\r\nbeing pasted is correct, and that I understand is what was fixed in a merge to Windows Terminal yesterday.And yes, I noticed later that the exception report I was getting with CTRL-J was different. (when my fix in #1108 didn't fix all the exceptions).
The CTRL-J (being accepted as CTRL-ENTER) causing an exception when the cursor scrolls to the top I think is fixed by #1108
SteveL-MSFT commentedon Nov 7, 2019
Carl Morris (@msftrncs) thanks for your contribution of #1108, however, what I'm seeing is that
PreviousLine()moves the cursor to the wrong line after inserting above. This causes the continuation line to be shown, but the cursor is on the line above it. So doing multiples of this causing an exception when it goes off screen.msftrncs commentedon Nov 7, 2019
I didn't think it was moving to the wrong line, but I will agree that when pasting with Windows Terminal's current behavior, one of two exceptions occur if the extra lines at the end of the buffer caused by the CTRL-ENTER force the insertion point to rise off the top of the screen.
One exception is a array out of bounds exception that occurs when the render occurs with the cursor top position being -1, due to logic that assumes a specific reason for the value.
A second exception is a typical top < 0 exception when the cursor position results in a value < -1, because the logic in the first exception is not triggered.
I saw all this happening because CTRL-ENTER is bound to InsertLineAbove, which pushes the current line down, The cursor is already on a new line because of the
\r, but that now new line is forced down by the\nwhich follows it. It appears that InsertLineAbove is creating new lines below, but that's not what is happening.SteveL-MSFT commentedon Nov 7, 2019
I'm prepping a PR, will cc you to reviewSteveL-MSFT commentedon Nov 7, 2019
I take it back. It seems that the problem is only if InsertLineAbove is used when the cursor is at the prompt. If it's within a line continuation then your change works as expected. So I think to fix one issue is to not allow InsertLineAbove when we know we are at a prompt.
msftrncs commentedon Nov 8, 2019
I think I ran in to what you were experiencing, Steve Lee (@SteveL-MSFT), just one time today, in VS Code. I have CTRL-J set to go to the terminal, where it becomes CTRL-ENTER. I had a VS Code window open for quite some time, and flipped to the terminal tab from output, it was the PowerShell Integrated Console from preview, and I pressed CTRL-J once, and the cursor went up one line above the prompt line. Repeating several more times and the cursor just stayed where it was (continuations appeared below). I cancelled and the cursor stayed up one line. I attempted again after getting a new prompt line, and I could not repeat it. I closed and re-opened the PowerShell session, and closed and opened VS Code, and could not repeat it again.
Don't SetCursorPosition when not Rendered.