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

No cursor (randomly) on profile startup #11411

Closed
vefatica opened this issue Oct 4, 2021 · 8 comments · Fixed by #12094
Closed

No cursor (randomly) on profile startup #11411

vefatica opened this issue Oct 4, 2021 · 8 comments · Fixed by #12094
Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@vefatica
Copy link

vefatica commented Oct 4, 2021

Windows Terminal version (or Windows build number)

Microsoft Windows 10 Pro for Workstations 10.0.19043.1237 (2009, 21H1) Windows Terminal Preview 1.11.2421.0

Other Software

No response

Steps to reproduce

Do these four steps repeatedly:

  1. Open the dropdown menu
  2. Click Powershell (or any profile, see below)
  3. Without supplying any input, observe whether the cursor appears or not
  4. Exit the shell

In case it matters, I use the Vintage, blinking cursor.

Expected Behavior

The cursor will always show.

Actual Behavior

The cursor shows (or not) randomly. The probability of it showing is about .8.

This affects all profiles. I've tested with Powershell, CMD, TCC, PWSH, Ubuntu, and SSH. When the cursor fails to show for an SSH profile, it fails to show at the password prompt.

When the cursor has failed to show, any keystroke, or WT losing/regaining the foreground will cause the cursor to become visible.

@ghost ghost 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 Oct 4, 2021
@zadjii-msft zadjii-msft added the Product-Terminal The new Windows Terminal. label Oct 5, 2021
@vefatica
Copy link
Author

Any further comment?

I've scripted the button-pushing and looking for the cursor and for five nights in a row, let the test run overnight, counting the attempts and the ones in which the cursor failed to show. The results are, for lack of a better word, striking. I'd be glad to share them if anyone's interested.

@zadjii-msft
Copy link
Member

Any further comment?

Not at the moment - We've been busy getting ready for 1.12 and are currently noticeably behind on triage. Off the top of my head, I don't know why this would happen, and haven't noticed it myself. That being said, gave it a go and did get it to happen a couple times so something is up.

@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Oct 14, 2021
@zadjii-msft zadjii-msft added Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) labels Oct 14, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Oct 14, 2021
@vefatica
Copy link
Author

Thanks for the reply, @zadjii-msft.

It seems to have something to do with the dropdown menu. In my testing (now automated), starting a new tab as described (click the menu button, click the profile) gives results like I described earlier, namely the cursor missing with some significant probability (see note below). If instead of using the dropdown menu I send (for example) Ctrl+Shift+1 I get ZERO instances with a missing cursor (in thousands of tries).

Note. The probability of the cursor being missing varies from instance to instance of WT. I have seen that probability as low as .05 and as high as .40.

In any event, if I let the test continue long enough (4000 - 5000 tries) the missing cursor instances will simply stop (and will not return in that instance of WT). And as mentioned in an old (now forgotten thread) that instance of WT (having opened/closed thousands of tabs) will be idling (1 tab), test finished) at 8% CPU (all of one processor).

Here's a picture of last night's test. The horizontal axis counts the number of Powershells started and the vertical axis shows the accumulated number of instances with the cursor missing. The test proceeds at exactly 20/minute so the graph represents about 8 hours.

image

@zadjii-msft
Copy link
Member

Well, that is... comprehensive. If you'd like to dig in further, I'm pretty sure the cursor blinker is set up here:

// Set up blinking cursor
int blinkTime = GetCaretBlinkTime();
if (blinkTime != INFINITE)
{
// Create a timer
DispatcherTimer cursorTimer;
cursorTimer.Interval(std::chrono::milliseconds(blinkTime));
cursorTimer.Tick({ get_weak(), &TermControl::_CursorTimerTick });
_cursorTimer.emplace(std::move(cursorTimer));
// As of GH#6586, don't start the cursor timer immediately, and
// don't show the cursor initially. We'll show the cursor and start
// the timer when the control is first focused. cursorTimer.Start();
_core.CursorOn(false);
}
else
{
// The user has disabled cursor blinking
_cursorTimer = std::nullopt;
}

@DHowett DHowett removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Oct 15, 2021
@ffes
Copy link

ffes commented Dec 21, 2021

I am experiencing exactly the same problem. For me the cursor is gone more often then it is shown. It indeed seems to be related to using the dropdown menu to open a new profile. When I use a keyboard shortcut or the command panel to start a new profile the cursor seems to be shown always.

It is funny to see when I open a Dev CMD for Visual Studio the cursor is shown before the batch file is executed that initializes the Dev CMD. As soon as the prompt is shown, the cursor is not shown anymore.

FYI, this are my cursor settings (it's a snippet obviously):

"profiles": 
{
     "defaults": 
     {
         "cursorColor": "#048322",
         "cursorShape": "filledBox"
     }
},

@zadjii-msft zadjii-msft modified the milestones: Terminal v2.0, 22H2 Jan 4, 2022
@zadjii-msft
Copy link
Member

// the timer when the control is first focused. cursorTimer.Start();
_core.CursorOn(false);

// ... cursorTimer.Start();

Uh, what did I do there...?

@ghost ghost added the In-PR This issue has a related PR label Jan 5, 2022
@ghost ghost closed this as completed in #12094 Jan 10, 2022
ghost pushed a commit that referenced this issue Jan 10, 2022
I'm not 100% sure that this is the right solution, but it does seem to work well enough. This is unfortunately a classic heisenbug. It was already hard enough to repro originally, but attaching a debugger made it totally impossible to hit. 

My theory is that it's possible for the GotFocus event to fire before the LayoutUpdated event does. If that were to occur, then we'd try to turn on the cursor timer before it exists, gracefully do nothing, then create the timer. In that case, we'd never get a subsequent message to start the blinking. 

I tested that theory by just initializing the cursor blinker to our `_focused` state. In that case, if the control has already been focused at the time of the LayoutUpdated event, then we can init the cursor to the correct state. Testing that out, I couldn't once get this to repro, which makes me think this works. I've opened some 900 (<sup>hyperbole</sup>) tabs now, so I'm pretty confident I'd have seen it by now.


* Regressed in #10978
* [x] fixes #11411
* [x] I made sure I didn't regress #6586
* [x] I work here
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Jan 10, 2022
DHowett pushed a commit that referenced this issue Jan 21, 2022
I'm not 100% sure that this is the right solution, but it does seem to work well enough. This is unfortunately a classic heisenbug. It was already hard enough to repro originally, but attaching a debugger made it totally impossible to hit.

My theory is that it's possible for the GotFocus event to fire before the LayoutUpdated event does. If that were to occur, then we'd try to turn on the cursor timer before it exists, gracefully do nothing, then create the timer. In that case, we'd never get a subsequent message to start the blinking.

I tested that theory by just initializing the cursor blinker to our `_focused` state. In that case, if the control has already been focused at the time of the LayoutUpdated event, then we can init the cursor to the correct state. Testing that out, I couldn't once get this to repro, which makes me think this works. I've opened some 900 (<sup>hyperbole</sup>) tabs now, so I'm pretty confident I'd have seen it by now.

* Regressed in #10978
* [x] fixes #11411
* [x] I made sure I didn't regress #6586
* [x] I work here

(cherry picked from commit 55aea08)
@ghost
Copy link

ghost commented Feb 3, 2022

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

Handy links:

@zamadatix
Copy link

In v1.13.10336.0 I now don't see the cursor at all:

image

It also doesn't show in the settings preview:
image

This issue was closed.
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.) Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants