Cursor droppings are back in conhost #17053

Closed
opened 2026-01-31 05:30:54 +00:00 by claunia · 6 comments
Owner

Originally created by @j4james on GitHub (Mar 22, 2022).

Originally assigned to: @lhecker on GitHub.

Windows Terminal version

OpenConsole 8a34a0e59a

Windows build number

10.0.19041.1415

Other Software

No response

Steps to reproduce

  1. You must be using a somewhat recent version of OpenConsole.
  2. Open a WSL bash shell.
  3. Execute the following: printf "\e[2 q\e[9999C "; sleep 1

The CSI 2 q is to get a non-blinking cursor which makes the issue easier to produce. The CSI 9999C moves the cursor to the end of the line, and the space initiates a delayed wrap. The sleep then gives the cursor a chance to be rendered before the next output will trigger the actual wrap.

Expected Behavior

The output should wrap to the next line without leaving a visible cursor block behind.

Actual Behavior

The cursor at the end of the line isn't cleared when the output wraps, so you end up with two cursors visible on the screen.

image

This doesn't occur in my inbox version of conhost, so I think it might be a regression.

Originally created by @j4james on GitHub (Mar 22, 2022). Originally assigned to: @lhecker on GitHub. ### Windows Terminal version OpenConsole 8a34a0e59ac41bc805c308fb82bc7683e583d45d ### Windows build number 10.0.19041.1415 ### Other Software _No response_ ### Steps to reproduce 1. You must be using a somewhat recent version of OpenConsole. 2. Open a WSL bash shell. 3. Execute the following: `printf "\e[2 q\e[9999C "; sleep 1` The `CSI 2 q` is to get a non-blinking cursor which makes the issue easier to produce. The `CSI 9999C` moves the cursor to the end of the line, and the space initiates a delayed wrap. The sleep then gives the cursor a chance to be rendered before the next output will trigger the actual wrap. ### Expected Behavior The output should wrap to the next line without leaving a visible cursor block behind. ### Actual Behavior The cursor at the end of the line isn't cleared when the output wraps, so you end up with two cursors visible on the screen. ![image](https://user-images.githubusercontent.com/4181424/159455638-1195fc5b-bea1-4e0f-8820-75bfd8d10318.png) This doesn't occur in my inbox version of conhost, so I think it might be a regression.
Author
Owner

@zadjii-msft commented on GitHub (Mar 22, 2022):

DROP EVERYTHING, THEY'RE BACK.

Thanks for noticing! Definitely can't let these back into the world 😝

@zadjii-msft commented on GitHub (Mar 22, 2022): DROP EVERYTHING, THEY'RE BACK. Thanks for noticing! Definitely can't let these back into the world 😝
Author
Owner

@j4james commented on GitHub (Mar 22, 2022):

I think this was broken by the deferred cursor drawing introduced in PR #10394. I can fix it by removing the StartDeferDrawing and EndDeferDrawing here:

f936c4443d/src/host/outputStream.cpp (L45-L55)

But then we lose the performance improvements we were getting from the PR. Hopefully there's a way to fix it without undoing that completely.

@j4james commented on GitHub (Mar 22, 2022): I think this was broken by the deferred cursor drawing introduced in PR #10394. I can fix it by removing the `StartDeferDrawing` and `EndDeferDrawing` here: https://github.com/microsoft/terminal/blob/f936c4443d4b7b11da32077b0dc0a9aa8652bc77/src/host/outputStream.cpp#L45-L55 But then we lose the performance improvements we were getting from the PR. Hopefully there's a way to fix it without undoing that completely.
Author
Owner

@j4james commented on GitHub (Mar 22, 2022):

I've got a possible solution that doesn't require undoing the deferred drawing. We save the current cursor position in StartDeferDrawing, and then trigger a redraw for both the old and new positions in EndDeferDrawing (assuming the position has changed).

Hopefully the overhead of that additional maintenance doesn't outweigh the benefits we're getting from the deferred drawing, but I'm not the best person to evaluate the performance issues here. I'm also not positive this is going to work in all scenarios - need to play around with it some more.

@j4james commented on GitHub (Mar 22, 2022): I've got a possible solution that doesn't require undoing the deferred drawing. We save the current cursor position in `StartDeferDrawing`, and then trigger a redraw for both the old and new positions in `EndDeferDrawing` (assuming the position has changed). Hopefully the overhead of that additional maintenance doesn't outweigh the benefits we're getting from the deferred drawing, but I'm not the best person to evaluate the performance issues here. I'm also not positive this is going to work in all scenarios - need to play around with it some more.
Author
Owner

@zadjii-msft commented on GitHub (Apr 29, 2022):

Fixing #12917 doesn't magically fix this 😢

Note: only repros when you're above the bottom of the viewport, so the view doesn't scroll

@zadjii-msft commented on GitHub (Apr 29, 2022): Fixing #12917 doesn't magically fix this 😢 Note: only repros when you're above the bottom of the viewport, so the view doesn't scroll
Author
Owner

@zadjii-msft commented on GitHub (Dec 5, 2022):

Might get fixed by snapshots

@zadjii-msft commented on GitHub (Dec 5, 2022): Might get fixed by snapshots
Author
Owner

@ghost commented on GitHub (Jan 24, 2023):

:tada:This issue was addressed in #14640, which has now been successfully released as Windows Terminal Preview v1.17.1023.🎉

Handy links:

@ghost commented on GitHub (Jan 24, 2023): :tada:This issue was addressed in #14640, which has now been successfully released as `Windows Terminal Preview v1.17.1023`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.17.1023) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17053