3-line commands that scrolled the window in powershell visually duplicate if partially deleted #17451

Closed
opened 2026-01-31 05:42:56 +00:00 by claunia · 5 comments
Owner

Originally created by @omgitsraven on GitHub (May 10, 2022).

Windows Terminal version

1.12.10982.0

Windows build number

10.0.19044.0

Other Software

No response

Steps to reproduce

  1. Open Windows Terminal
  2. Open a Powershell terminal
  3. Press the enter key repeatedly, until the content of the window begins to scroll (so that the active prompt is at the bottom of the window.)
  4. Type a command that wraps onto three lines, but do not hit enter. (The command doesn't have to be valid, you can just hold down the q key.)
  5. Start deleting characters with the backspace key, until the command should fit onto two lines. (Go slightly past it fitting exactly; make some empty space on the end of the second line.)

Expected Behavior

You should see a two-line-long command after your prompt.

Actual Behavior

Once you delete enough characters to fit exactly on two lines, the window scrolls up for some reason... And then, once you delete one character MORE than that, the first two lines visually mash up to create a command that appears to still be three lines long! (The command actually still runs normally, it's just very confusing to edit...)

Here is an example, where I filled the first line with as, the second line with bs, and the third line with cs, and then deleted the third line and some of the second:

Before deleting anything:
image

After pressing backspace several times:
image

Also, note that this happens in Powershell running inside Windows Terminal, but NOT when attempted in the standalone Powershell prompt.

Originally created by @omgitsraven on GitHub (May 10, 2022). ### Windows Terminal version 1.12.10982.0 ### Windows build number 10.0.19044.0 ### Other Software _No response_ ### Steps to reproduce 1. Open Windows Terminal 2. Open a Powershell terminal 3. Press the enter key repeatedly, until the content of the window begins to scroll (so that the active prompt is at the *bottom* of the window.) 4. Type a command that wraps onto *three* lines, but do *not* hit enter. (The command doesn't have to be valid, you can just hold down the `q` key.) 5. Start *deleting* characters with the backspace key, until the command should fit onto two lines. (Go slightly *past* it fitting exactly; make some empty space on the end of the second line.) ### Expected Behavior You should see a two-line-long command after your prompt. ### Actual Behavior Once you delete enough characters to fit *exactly* on two lines, the window scrolls up for some reason... And then, once you delete one character MORE than that, the first two lines visually mash up to create a command that appears to still be three lines long! (The command actually still runs normally, it's just very confusing to edit...) Here is an example, where I filled the first line with `a`s, the second line with `b`s, and the third line with `c`s, and then deleted the third line and some of the second: Before deleting anything: ![image](https://user-images.githubusercontent.com/8540042/167512931-5b61beaf-3152-499b-840b-d3992e7473cc.png) After pressing backspace several times: ![image](https://user-images.githubusercontent.com/8540042/167512952-577281d1-d81c-4ec7-adc4-9d0ab465d432.png) Also, note that this happens in Powershell running inside Windows Terminal, but NOT when attempted in the *standalone* Powershell prompt.
claunia added the Issue-BugResolution-ExternalNeeds-Tag-Fix labels 2026-01-31 05:42:56 +00:00
Author
Owner

@j4james commented on GitHub (May 12, 2022):

I don't know what the problem is here, but I did briefly look into it, and I just wanted to note some of the things I discovered.

  1. When the PowerShell prompt wraps at the bottom of the viewport, it's just calling SetConsoleCursorPosition to position the cursor below the viewport bottom, and that triggers a SetViewportOrigin call which pans the viewport down. As far as I can tell, that viewport movement doesn't propagate over conpty as a scroll event, so you lose any lines that scroll off the top.
  2. When the prompt has wrapped over 3 lines, and you backspace to the start of that third line, PowerShell generates a linefeed for some reason. That forces the viewport to pan down an additional row leaving an extra blank line. You can see that in conhost too - it's not just a conpty thing. As weird as that is, though, it shouldn't be causing anything to break, but I thought it might be the trigger for whatever is subsequently going wrong.

It's also worth noting that point 1 is possibly the same bug we're seeing in #10905.

@j4james commented on GitHub (May 12, 2022): I don't know what the problem is here, but I did briefly look into it, and I just wanted to note some of the things I discovered. 1. When the PowerShell prompt wraps at the bottom of the viewport, it's just calling `SetConsoleCursorPosition` to position the cursor below the viewport bottom, and that triggers a `SetViewportOrigin` call which pans the viewport down. As far as I can tell, that viewport movement doesn't propagate over conpty as a scroll event, so you lose any lines that scroll off the top. 2. When the prompt has wrapped over 3 lines, and you backspace to the start of that third line, PowerShell generates a linefeed for some reason. That forces the viewport to pan down an additional row leaving an extra blank line. You can see that in conhost too - it's not just a conpty thing. As weird as that is, though, it shouldn't be causing anything to break, but I thought it might be the trigger for whatever is subsequently going wrong. It's also worth noting that point 1 is possibly the same bug we're seeing in #10905.
Author
Owner

@zadjii-msft commented on GitHub (May 16, 2022):

Oh, that does sound familiar, yea. @omgitsraven I wonder if an updated PsReadline might just fix this for you/?

@zadjii-msft commented on GitHub (May 16, 2022): Oh, that does sound familiar, yea. @omgitsraven I wonder if an updated PsReadline might just fix this for you/?
Author
Owner

@omgitsraven commented on GitHub (May 16, 2022):

Updating PSReadLine to 2.2.5 has fixed it!! Thank you :)

Does that mean I should close this issue then, if that fix will work its way to everyone eventually?

@omgitsraven commented on GitHub (May 16, 2022): Updating PSReadLine to 2.2.5 has fixed it!! Thank you :) Does that mean I should close this issue then, if that fix will work its way to everyone eventually?
Author
Owner

@zadjii-msft commented on GitHub (May 16, 2022):

Yea, we can close this out as /dup https://github.com/PowerShell/PSReadLine/issues/724

@zadjii-msft commented on GitHub (May 16, 2022): Yea, we can close this out as /dup https://github.com/PowerShell/PSReadLine/issues/724
Author
Owner

@ghost commented on GitHub (May 16, 2022):

Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!

@ghost commented on GitHub (May 16, 2022): Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17451