starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Closing a pane does not reset the PowerShell text position #3417

New Issue
Closed
opened 2026-01-30 23:20:49 +00:00 by claunia · 10 comments
claunia commented 2026-01-30 23:20:49 +00:00
Owner
Copy Link

Originally created by @richardszalay on GitHub (Aug 15, 2019).

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.175]
Windows Terminal version (if applicable): 0.3.2171.0

Steps to reproduce

  1. Create a PowerShell tab
  2. Press enter until the text covers most of the window
  3. Split the view horizontally
  4. Close the bottom pane
  5. Start typing

Expected behavior

Text appears at previous cursor line

Actual behavior

Text appears in blank space. Screenshots of process:

pane-text-1

pane-text-2

pane-text-3

Originally created by @richardszalay on GitHub (Aug 15, 2019). # Environment ```none Windows build number: Microsoft Windows [Version 10.0.18362.175] Windows Terminal version (if applicable): 0.3.2171.0 ``` # Steps to reproduce 1. Create a PowerShell tab 2. Press enter until the text covers most of the window 3. Split the view horizontally 4. Close the bottom pane 5. Start typing # Expected behavior Text appears at previous cursor line # Actual behavior Text appears in blank space. Screenshots of process: ![pane-text-1](https://user-images.githubusercontent.com/229467/63062276-9da01300-bf3b-11e9-9545-9b90e42dfb23.png) ![pane-text-2](https://user-images.githubusercontent.com/229467/63062280-a0026d00-bf3b-11e9-9db6-e424cf0b4b5f.png) ![pane-text-3](https://user-images.githubusercontent.com/229467/63062283-a395f400-bf3b-11e9-8b1c-cd0c66e44bc1.png)
claunia commented 2026-01-30 23:20:50 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 15, 2019):

So this is definitely a psreadline bug, though it does seem unique to Windows Terminal. Notably, I can't seem to repro a similar scenario in a conhost window:

  1. Do a wsl.exe powershell.exe to get a conpty running powershell in a conhost window.
  2. fill the buffer
  3. Resize down so the prompt is in the middle of the buffer
  4. Resize up again
  5. type anything

If this was a purely psreadline or conpty bug, then this wouldn't repro in this scenario. We'll need to do something better with the Terminal specifically.

@zadjii-msft commented on GitHub (Aug 15, 2019): So this is _definitely_ a psreadline bug, though it does seem unique to Windows Terminal. Notably, I can't seem to repro a similar scenario in a conhost window: 1. Do a `wsl.exe powershell.exe` to get a conpty running powershell in a conhost window. 2. fill the buffer 3. Resize down so the prompt is in the middle of the buffer 4. Resize up again 5. type anything If this was a purely psreadline or conpty bug, then this wouldn't repro in this scenario. We'll need to do something better with the Terminal specifically.
claunia commented 2026-01-30 23:20:50 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Aug 16, 2019):

This is partially related to the fact that PowerShell saves and restores your cursor position across taking prompt input. That's also the cause of #2267.

@DHowett-MSFT commented on GitHub (Aug 16, 2019): This is partially related to the fact that PowerShell saves and restores your cursor position across taking prompt input. That's also the cause of #2267.
claunia commented 2026-01-30 23:20:50 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 13, 2020):

Okay with #4741 merged, this is still happening. I'm pretty sure PsReadline is saving the cursor position at the start of the prompt, and restores the position when it wants to redraw the terminal. Though, the question I have is "why isn't this happening if you just decrease, then increase the height of the terminal"

This discussion from VTE seemed relevant, but I'm not sure

https://gitlab.gnome.org/GNOME/vte/blob/master/doc/rewrap.txt

Shell prompt
────────────

If you resize the terminal to be narrower than your shell prompt (plus the
command you're entering) while the shell is waiting for your command, you see
weird behavior there. This is not a bug in rewrapping: it's because the shell
redisplays its prompt (and command line) on every resize. There's not much VTE
could do here.

As a long term goal, maybe readline could have an option where it knows that
the terminal rewraps its contents so that it doesn't redisplay the prompt and
the command line, just expects the terminal to do this correctly. It's a bit
risky, since probably all terminals that support rewrapping do this a little
bit differently.

EDIT 3-17-2020

image

Okay this definitely isn't a unique problem to the Windows Terminal, but it might only be trigger-able in the Windows Terminal. The above screenshot shows WT side-by-side with the conpty that's hosting it. As you can see, in that conpty, the cursor position jumped to the bottom of the viewport. So the Terminal is doing exactly what conpty told it to here.

But if you just normally resize the Terminal, it works fine:
image

This also seems to repro with the wsl version of pwsh, which I have 7.0.0 installed. So it's not uniquely Windows/the Win32 API that this is happening with.

When I do the whole split-pane, close pane repro with a breakpoint in ScreenBufferSizeChange in the first conpty, I get the following:

<split pane here>
ScreenBufferSizeChange(79, 11)
ScreenBufferSizeChange(79, 11)
conpty: 24136
ScreenBufferSizeChange(79, 12)
ScreenBufferSizeChange(79, 12)
<close pane here>
ScreenBufferSizeChange(79, 24)
ScreenBufferSizeChange(79, 24)

A bunch of resizes down to the smaller size, then a pair back up to the larger size.

@zadjii-msft commented on GitHub (Mar 13, 2020): Okay with #4741 merged, this is still happening. I'm pretty sure PsReadline is saving the cursor position at the start of the prompt, and restores the position when it wants to redraw the terminal. Though, the question I have is "_why isn't this happening if you just decrease, then increase the height of the terminal_" <details> <summary>This discussion from VTE seemed relevant, but I'm not sure </summary> https://gitlab.gnome.org/GNOME/vte/blob/master/doc/rewrap.txt ``` Shell prompt ──────────── If you resize the terminal to be narrower than your shell prompt (plus the command you're entering) while the shell is waiting for your command, you see weird behavior there. This is not a bug in rewrapping: it's because the shell redisplays its prompt (and command line) on every resize. There's not much VTE could do here. As a long term goal, maybe readline could have an option where it knows that the terminal rewraps its contents so that it doesn't redisplay the prompt and the command line, just expects the terminal to do this correctly. It's a bit risky, since probably all terminals that support rewrapping do this a little bit differently. ``` </details> <hr> ### EDIT 3-17-2020 ![image](https://user-images.githubusercontent.com/18356694/76895027-39d92200-685d-11ea-8da9-75b7c212bccb.png) Okay this definitely isn't a _unique_ problem to the Windows Terminal, but it might only be trigger-able in the Windows Terminal. The above screenshot shows WT side-by-side with the conpty that's hosting it. As you can see, in that conpty, the cursor position jumped to the bottom of the viewport. So the Terminal is doing exactly what conpty told it to here. But if you just normally resize the Terminal, it works fine: ![image](https://user-images.githubusercontent.com/18356694/76895466-0f3b9900-685e-11ea-93f1-cc82e131b58a.png) This also seems to repro with the wsl version of `pwsh`, which I have 7.0.0 installed. So it's not _uniquely_ Windows/the Win32 API that this is happening with. When I do the whole split-pane, close pane repro with a breakpoint in `ScreenBufferSizeChange` in the first conpty, I get the following: ``` <split pane here> ScreenBufferSizeChange(79, 11) ScreenBufferSizeChange(79, 11) conpty: 24136 ScreenBufferSizeChange(79, 12) ScreenBufferSizeChange(79, 12) <close pane here> ScreenBufferSizeChange(79, 24) ScreenBufferSizeChange(79, 24) ``` A bunch of resizes _down_ to the smaller size, then a pair back up to the larger size.
claunia commented 2026-01-30 23:20:51 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 17, 2020):

@lzybkr, @stevel-msft

Any ideas what might be going on here? I'm thinking that PSReadline is restoring the cursor relative to the bottom of the viewport, but I don't know where in PSReadline's code I'd go to check that out.

@zadjii-msft commented on GitHub (Mar 17, 2020): @lzybkr, @stevel-msft Any ideas what might be going on here? I'm thinking that PSReadline is restoring the cursor _relative to the bottom of the viewport_, but I don't know where in PSReadline's code I'd go to check that out.
claunia commented 2026-01-30 23:20:51 +00:00
Author
Owner
Copy Link

@lzybkr commented on GitHub (Mar 18, 2020):

The cursor position is saved after the prompt here.

Console resizing has always a bit of problem, but mostly nobody noticed when the code was originally written because resizing used to be awkward. I considered moving away from .Net to INPUT_RECORD to get the resize events early in Win10 when resizing a console became much easier, but that would have made the code much less portable so I'm glad I didn't.

@lzybkr commented on GitHub (Mar 18, 2020): The cursor position is saved after the prompt [here](https://github.com/PowerShell/PSReadLine/blob/198a64390e713214df20ef580f7a546b5c3ac1e8/PSReadLine/ReadLine.cs#L696). Console resizing has always a bit of problem, but mostly nobody noticed when the code was originally written because resizing used to be awkward. I considered moving away from .Net to INPUT_RECORD to get the resize events early in Win10 when resizing a console became much easier, but that would have made the code much less portable so I'm glad I didn't.
claunia commented 2026-01-30 23:20:51 +00:00
Author
Owner
Copy Link

@lzybkr commented on GitHub (Mar 18, 2020):

BTW, @daxian-dbw maintains PSReadLine now.

@lzybkr commented on GitHub (Mar 18, 2020): BTW, @daxian-dbw maintains PSReadLine now.
claunia commented 2026-01-30 23:20:51 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 19, 2020):

Okay I'm just pasting here for my future reference code that looks relevant
This issue: https://github.com/PowerShell/PSReadLine/issues/682
and the associated PR: https://github.com/PowerShell/PSReadLine/pull/694

Which pointed me to this function
198a64390e/PSReadLine/Render.cs (L985-L1000)

I can't be sure that's actually it, but that's certainly something to look into.

It looks like I've got 2.0.0 on my powershell 5 instance, and 2.0.0-beta3 on my powershell 6.2.3 instance.

Though, reading through that, it looks like _console.CursorTop might already be wrong at that point in the call. Looks like that function is just trying to see how many rows the input line takes, then is setting the _initialY to be that many rows above the cursor. So I'd think the cursor was already wrong at this point.

I'll keep digging

@zadjii-msft commented on GitHub (Mar 19, 2020): Okay I'm just pasting here for my future reference code that looks relevant This issue: https://github.com/PowerShell/PSReadLine/issues/682 and the associated PR: https://github.com/PowerShell/PSReadLine/pull/694 Which pointed me to this function https://github.com/PowerShell/PSReadLine/blob/198a64390e713214df20ef580f7a546b5c3ac1e8/PSReadLine/Render.cs#L985-L1000 I can't be sure that's actually it, but that's certainly something to look into. It looks like I've got 2.0.0 on my powershell 5 instance, and 2.0.0-beta3 on my powershell 6.2.3 instance. Though, reading through that, it looks like `_console.CursorTop` might already be wrong at that point in the call. Looks like that function is just trying to see how many rows the input line takes, then is setting the `_initialY` to be that many rows above the cursor. So I'd think the cursor was already wrong at this point. I'll keep digging
claunia commented 2026-01-30 23:20:51 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 6, 2020):

A simpler repro from #5254

Steps to reproduce

  1. Open Terminal in full screen
  2. Type ls
  3. unmaximize the window
  4. maximize the window
  5. type ls again and see that ls is not positioned correctly

displaybug

More investigation from today

With a plain old conhost:

  • Maximize it
  • Run ls
  • Restore down
  • Change the buffer size to match the window size
  • Maximize again

this will repro without conpty. I'm struggling to figure this out on our side so I'm going to move this upstream to https://github.com/PowerShell/PSReadLine/issues/1456

@zadjii-msft commented on GitHub (Apr 6, 2020): A simpler repro from #5254 > # Steps to reproduce > > 1. Open Terminal in full screen > 2. Type `ls` > 3. unmaximize the window > 4. maximize the window > 5. type `ls` again and see that ls is not positioned correctly > > > ![displaybug](https://user-images.githubusercontent.com/18528548/78541017-45cd5980-77f5-11ea-95aa-d34eb2eef788.gif) <hr> More investigation from today With a plain old conhost: - Maximize it - Run `ls` - Restore down - _Change the buffer size to match the window size_ - Maximize again this will repro without conpty. I'm struggling to figure this out on our side so I'm going to move this upstream to https://github.com/PowerShell/PSReadLine/issues/1456
claunia commented 2026-01-30 23:20:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 24, 2022):

This may have been fixed in an updated PsReadline. Just need to confirm.

🎉 This issue was addressed in 3074, which has now been successfully released in v2.2.0-beta5. 🎉

@zadjii-msft commented on GitHub (Jan 24, 2022): This may have been fixed in an updated PsReadline. Just need to confirm. > 🎉 This issue was addressed in 3074, which has now been successfully released in [`v2.2.0-beta5`](https://github.com/PowerShell/PSReadLine/releases/tag/v2.2.0-beta5). 🎉
claunia commented 2026-01-30 23:20:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 18, 2022):

Just confirmed over here that this looks like it was fixed in PSReadline 🙌

@zadjii-msft commented on GitHub (Aug 18, 2022): Just confirmed over here that this looks like it was fixed in PSReadline 🙌
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT Help Wanted Issue-Bug Priority-2 Product-Terminal Resolution-External Tracking-External
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#3417
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?