Cursor desync in Far Manager #22019

Closed
opened 2026-01-31 08:01:08 +00:00 by claunia · 5 comments
Owner

Originally created by @o-sdn-o on GitHub (Jul 27, 2024).

Windows Terminal version

current main

Windows build number

10.0.19045.4651

Other Software

Far Manager, version 3.0.6352.0 x64

Steps to reproduce

  1. Launch the latest Far Manager.
  2. Press Ctrl+O to hide panels.
  3. Press Enter (run empty command).

Expected Behavior

The cursor should remain at the command line prompt.

Actual Behavior

The cursor unexpectedly moved to the lower right corner (conhost is ok ,WT is affected).

https://github.com/user-attachments/assets/a95f71c8-d13c-4b4c-ac5e-902ca6f46932

This issue came up right after #17194.

Originally created by @o-sdn-o on GitHub (Jul 27, 2024). ### Windows Terminal version current main ### Windows build number 10.0.19045.4651 ### Other Software Far Manager, version 3.0.6352.0 x64 ### Steps to reproduce 1. Launch the latest Far Manager. 2. Press `Ctrl+O` to hide panels. 3. Press `Enter` (run empty command). ### Expected Behavior The cursor should remain at the command line prompt. ### Actual Behavior The cursor unexpectedly moved to the lower right corner (conhost is ok ,WT is affected). https://github.com/user-attachments/assets/a95f71c8-d13c-4b4c-ac5e-902ca6f46932 This issue came up right after #17194.
claunia added the Needs-TriageIssue-Bug labels 2026-01-31 08:01:08 +00:00
Author
Owner

@j4james commented on GitHub (Jul 28, 2024):

As far as I can make out, we get a linefeed at the bottom of the page which triggers an InvalidateFlush setting the _circled flag. This occurs in a frame with no other changes, so the VtEngine::StartPaint doesn't think there's anything to do, and as a result we never execute the VtEngine::EndPaint, which is where the _circled flag is usually handled and reset.

The next thing that happens is that the cursor is moved to its expected position after the prompt, but the _circled flag will still be set when we paint the next frame, and that prevents the cursor from being "painted" (which is how its position is passed through to conpty). See the code here:

295cd17b02/src/renderer/vt/XtermEngine.cpp (L210-L213)

One possible fix would be to add the _circled flag to the list of things that are checked when determining whether there's something for the renderer to do, i.e. just add it to the condition here:

295cd17b02/src/renderer/vt/paint.cpp (L33-L37)

That seems to fix the issue for me, but I don't fully understand the circling behavior, so there might be more to it than that.

@j4james commented on GitHub (Jul 28, 2024): As far as I can make out, we get a linefeed at the bottom of the page which triggers an `InvalidateFlush` setting the `_circled` flag. This occurs in a frame with no other changes, so the `VtEngine::StartPaint` doesn't think there's anything to do, and as a result we never execute the `VtEngine::EndPaint`, which is where the `_circled` flag is usually handled and reset. The next thing that happens is that the cursor is moved to its expected position after the prompt, but the `_circled` flag will still be set when we paint the next frame, and that prevents the cursor from being "painted" (which is how its position is passed through to conpty). See the code here: https://github.com/microsoft/terminal/blob/295cd17b028d288ff81445f532d9301b44f6ffd9/src/renderer/vt/XtermEngine.cpp#L210-L213 One possible fix would be to add the `_circled` flag to the list of things that are checked when determining whether there's something for the renderer to do, i.e. just add it to the condition here: https://github.com/microsoft/terminal/blob/295cd17b028d288ff81445f532d9301b44f6ffd9/src/renderer/vt/paint.cpp#L33-L37 That seems to fix the issue for me, but I don't fully understand the circling behavior, so there might be more to it than that.
Author
Owner

@lhecker commented on GitHub (Jul 29, 2024):

Does this issue repro in Windows Terminal Canary?

If it doesn't repro there, I'd personally like to avoid fixing VtEngine, because I don't fully understand the nuances of the circling behavior either. Seemingly innocent fixes in that area in the past have repeatedly caused regressions.

@lhecker commented on GitHub (Jul 29, 2024): Does this issue repro in Windows Terminal Canary? If it doesn't repro there, I'd personally like to avoid fixing `VtEngine`, because I don't fully understand the nuances of the circling behavior either. Seemingly innocent fixes in that area in the past have repeatedly caused regressions.
Author
Owner

@o-sdn-o commented on GitHub (Jul 29, 2024):

Does this issue repro in Windows Terminal Canary?

Isn't the current main branch the same thing? (this issue is reproducible on the current main branch)

@o-sdn-o commented on GitHub (Jul 29, 2024): > Does this issue repro in Windows Terminal Canary? Isn't the current main branch the same thing? (this issue is reproducible on the current main branch)
Author
Owner

@DHowett commented on GitHub (Jul 29, 2024):

Isn't the current main branch the same thing?

Not currently. We're building Canary out of a merge between a couple in-flight branches right now.

@DHowett commented on GitHub (Jul 29, 2024): > Isn't the current main branch the same thing? Not currently. We're building Canary out of a merge between a couple in-flight branches right now.
Author
Owner

@o-sdn-o commented on GitHub (Jul 29, 2024):

This issue is not reproducible in the dev/lhecker/goodbye-vtengine branch.

@o-sdn-o commented on GitHub (Jul 29, 2024): This issue is not reproducible in the [`dev/lhecker/goodbye-vtengine`](https://github.com/microsoft/terminal/tree/dev/lhecker/goodbye-vtengine) branch.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#22019