Incorrect caret position and text output #13574

Closed
opened 2026-01-31 03:46:12 +00:00 by claunia · 2 comments
Owner

Originally created by @zzsergant on GitHub (Apr 20, 2021).

Windows Terminal version (or Windows build number)

Microsoft Windows 10.0.19042, Terminal 1.7.1033.0

Other Software

No response

Steps to reproduce

  1. Start new Windows Terminal instance from windows taskbar (it runs in the C:\Windows\System32 folder). The window must not be maximized.
  2. Type: ls
  3. Press and hold: a key

Expected Behavior

The terminal show a long line with a characters after a list of files.

Actual Behavior

After a few a characters the carret position jumps a few lines above and output the remaining characters there.

Screenshot 2021-04-20 201924

This behavior is not 100% reproducible. I guess it is related to window position somehow. I can reproduce this bug 1 or 2 times from 10 runs.

When it broke that way and I maximize window and then return it to old size, then type clear the bug fixes and not appear in than instance of terminal anymore.

However, if I not maximize/return the window size back and just type clear the bug is reproduced again in that instance.

Maybe it is related to some unitialized variable?

This bug is not new. The first time I've noticed it was around 20H2 Windows Update.

Originally created by @zzsergant on GitHub (Apr 20, 2021). ### Windows Terminal version (or Windows build number) Microsoft Windows 10.0.19042, Terminal 1.7.1033.0 ### Other Software No response ### Steps to reproduce 1. Start new Windows Terminal instance from windows taskbar (it runs in the C:\Windows\System32 folder). The window must not be maximized. 2. Type: `ls` 3. Press and hold: `a` key ### Expected Behavior The terminal show a long line with `a` characters after a list of files. ### Actual Behavior After a few `a` characters the carret position jumps a few lines above and output the remaining characters there. <img width="652" alt="Screenshot 2021-04-20 201924" src="https://user-images.githubusercontent.com/8413756/115441117-2c892680-a219-11eb-84f2-ab3e86a70ca3.png"> This behavior is not 100% reproducible. I guess it is related to window position somehow. I can reproduce this bug 1 or 2 times from 10 runs. When it broke that way and I maximize window and then return it to old size, then type `clear` the bug fixes and not appear in than instance of terminal anymore. However, if I not maximize/return the window size back and just type `clear` the bug is reproduced again in that instance. Maybe it is related to some unitialized variable? This bug is not new. The first time I've noticed it was around 20H2 Windows Update.
claunia added the Resolution-Duplicate label 2026-01-31 03:46:12 +00:00
Author
Owner

@zadjii-msft commented on GitHub (Apr 21, 2021):

Thanks for the report! This is actually already being tracked by another issue on our repo - please refer to #6546 for more discussion.

/dup #6546

If you've got an absolutely consistent repro, I'd appreciate it in that thread 😄

@zadjii-msft commented on GitHub (Apr 21, 2021): Thanks for the report! This is actually already being tracked by another issue on our repo - please refer to #6546 for more discussion. /dup #6546 If you've got an absolutely consistent repro, I'd appreciate it in that thread 😄
Author
Owner

@ghost commented on GitHub (Apr 21, 2021):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Apr 21, 2021): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. 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#13574