Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sp; mf ... leaves cursor visible in the inactive pane #17850

Open
vefatica opened this issue Sep 3, 2024 · 8 comments
Open

sp; mf ... leaves cursor visible in the inactive pane #17850

vefatica opened this issue Sep 3, 2024 · 8 comments
Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal.
Milestone

Comments

@vefatica
Copy link

vefatica commented Sep 3, 2024

When I, for example, wt sp cmd.exe; mf 1, the cursor remains visible in the inactive pane. This is unlike moving focus in other situations; normally the cursor is hidden in an inactive pane.

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Sep 3, 2024
@zadjii-msft
Copy link
Member

Version number?

@vefatica
Copy link
Author

vefatica commented Sep 3, 2024

That was the 20 release and the 21 preview. I just updated and the same is true of WindowsTerminal 1.22.2408.23002 (preview) and WindowsTerminal 1.21.2408.23001.

And I'm seeing this for the first time when starting the 1.21 release.

image

That's apparently from

        {
            "id": null,
            "keys": "ctrl+shift+w"
        },

Any idea?

@vefatica
Copy link
Author

vefatica commented Sep 9, 2024

When I, for example, wt sp cmd.exe; mf 1, the cursor remains visible in the inactive pane. This is unlike moving focus in other situations; normally the cursor is hidden in an inactive pane.

Any more on this?

@vefatica
Copy link
Author

If you have looked into this you've probably figured out that it's a matter of timing. I can reproduce the undesirable behavior (cursor showing in the inactive pane) with simulated keystrokes (using TCC's KEYSTACK command).

keystack alt-shift-+ alt-left

If I introduce a delay (9/18 second below) before moving focus, the cursor is not showing in the inactive pane.

keystack alt-shift-+ /w9 alt-left

@lhecker
Copy link
Member

lhecker commented Sep 16, 2024

And I'm seeing this for the first time when starting the 1.21 release.

Is the null from you or automatically generated by us? I'm assuming the latter. In that case I think it's a bug in #17162 and I suppose we fail to remove bindings that have no action?

@lhecker
Copy link
Member

lhecker commented Sep 16, 2024

I believe this issue also happens even if all you do is unfocus the application, while the terminal is currently busy with processing output that doesn't move the cursor (= pure VT).

DispatchTimer::Stop neither cancels the pending nor blocks until the queued event is done:

If Stop is called when the timer interval has just elapsed, it's possible that the timer already queued a Tick event. This event will still be raised.

So, when we do "stop the timer, then disable the cursor", we may still get a blink tick.

@lhecker lhecker added Issue-Bug It either shouldn't be doing this or needs an investigation. Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Product-Terminal The new Windows Terminal. Priority-3 A description (P3) and removed Needs-Tag-Fix Doesn't match tag requirements labels Sep 16, 2024
@vefatica
Copy link
Author

I don't think I put that null in there.

@vefatica
Copy link
Author

I found other ways to leave the cursor showing in an inactive pane also. One is to just do the keystrokes quickly enough ... Alt-Shift-+, Alt-Left.

@carlos-zamora carlos-zamora added this to the Backlog milestone Sep 25, 2024
@carlos-zamora carlos-zamora removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

4 participants