The current cursor is off after window resizing #3637

Activity

1. ghost added

   Needs-Triage 🔍It's a new issue that core contributor team needs to triage.It's a new issue that core contributor team needs to triage.

   on Mar 27, 2023
2. Steven Bucher (StevenBucher98)

   added

   Issue-BugIt either shouldn't be doing this or needs an investigation.It either shouldn't be doing this or needs an investigation.

   and removed

   Needs-Triage 🔍It's a new issue that core contributor team needs to triage.It's a new issue that core contributor team needs to triage.

   on Mar 27, 2023
3. StevenBucher98 commented on Mar 27, 2023

   

   Steven Bucher (StevenBucher98)

   on Mar 27, 2023

   Collaborator

   More actions

   This is a known issue, its tricky because PSReadLine does not get constant updates on Window Change events in a cross platform way. Marking as bug and will explore possible solutions
4. Dongbo Wang (daxian-dbw)

   changed the title [-]Corrupted terminal output after window resized[/-] [+]The current cursor is off after window resizing[/+] on Mar 27, 2023
5. RoadToDream commented on Mar 27, 2023

   

   Jiawei Duan (RoadToDream)

   on Mar 27, 2023

   Author

   More actions

   This is a known issue, its tricky because PSReadLine does not get constant updates on Window Change events in a cross platform way. Marking as bug and will explore possible solutions

   Hi Steven Bucher (@StevenBucher98) , thank you for confirming the issue. Looking forward a fix in the future.
6. lulu-loopp commented on Aug 12, 2026

   

   Weiyi Shi (lulu-loopp)

   on Aug 12, 2026

   More actions

   I dug into this while working on a terminal, and I think the mechanism is worth writing down, because part of it has a small fix and part of it does not.

   Where the column comes from. After a buffer width change, RecomputeInitialCoords recovers the column of the edit anchor with one statement, in both of its branches (Render.cs#L1261, Render.cs#L1297):

   // Recompute X from the buffer width:
   _initialX %= _console.BufferWidth;

   _initialX is the anchor's column at the width in effect before the resize, so it already is the prompt's cell width reduced modulo that width. Reducing it again keeps the remainder and throws away the quotient, and the quotient is the only record of how many physical lines the prompt spans. Once it is gone, widening cannot put the anchor back.

   The numbers in this report fit that exactly. The prompt

   PS C:\Program Files\Windows Defender Advanced Threat Protection\Classification>
   

   is 79 cells including the trailing space, and the reported corruption is

   PS C:\Program FilelsWindows Defender Advanced Threat Protection\Classification>
   

   which puts ls at column 18. 79 % 61 == 18, i.e. the window was about 61 columns wide before it was maximized, the prompt occupied two physical lines there, and after maximizing PSReadLine still believed the anchor was at column 18.

   Minimal repro (measured on Windows PowerShell 5.1 with the inbox 2.0.0, and on pwsh 7.6.4 with 2.4.5; both through a ConPTY pseudoconsole, which is the path conhost and Windows Terminal use):

   # 36 cells wide
   function prompt { 'PSRL-ANCHOR-PROBE-0123456789012345> ' }

   1. Size the window to 100 columns, press Enter for a fresh prompt, type some text, and do not press Enter.
   2. Narrow the window to 35 columns -- narrower than the prompt -- and type one character. This still renders correctly.
   3. Widen the window back to 100 columns and type one more character. The input is now redrawn from column 1, on top of the prompt, and the text drawn at the narrow width is left on screen.

   Reading back the CUP sequences, the anchor is at column 1 after step 3 where it should be at column 36; the same is true for 100 -> 20 -> 100, 100 -> 10 -> 100, and 100 -> 35 -> 60 -> 25 -> 100. 2.0.0 and 2.4.5 behave identically, which is expected: the statement dates to 2017 (b2979d1) and #3074 carried it forward unchanged.

   PR #5191 keeps the prompt's cell width -- a quantity that does not depend on the buffer width -- and derives _initialX from it on every width change. That fixes every case above: narrowing is unchanged and widening restores the anchor, including across several successive resizes.

   What it does not fix, and why. The steps in this issue start with the prompt already wrapped, before ReadLine is entered. In that situation the only thing PSReadLine can observe is CursorLeft, which is already the reduced value (18 in the example above), so the prompt's true width of 79 is not recoverable without re-invoking the user's prompt function or reading the screen buffer back. So this issue's exact repro will still misbehave after that PR; what changes is that resizing during an edit -- the far more frequent way people hit this -- no longer corrupts the line. I did not want to fold a prompt re-invocation into a small fix without maintainer input, but I am happy to follow up on that half if there is a preferred approach.
7. Weiyi Shi (lulu-loopp)

   added a commit that references this issue on Aug 18, 2026

   Recover the edit anchor from the cursor when the buffer width changes

   ...

   8fba17e