Repository: microsoft/terminal (language: cpp)

Issue:
No cursor (randomly) on profile startup
### 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.


Discussion / hints:
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.
> 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.  
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](https://user-images.githubusercontent.com/61856645/137236205-cced3141-9ce1-4e33-b6de-8d1792eeb326.png)

Well, that is... comprehensive. If you'd like to dig in further, I'm pretty sure the cursor blinker is set up here: https://github.com/microsoft/terminal/blob/02ac246807993e57dd5b6061bee1385f186ae20d/src/cascadia/TerminalControl/TermControl.cpp#L684-L702
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):
 
```json
"profiles": 
{
     "defaults": 
     {
         "cursorColor": "#048322",
         "cursorShape": "filledBox"
     }
},
```
https://github.com/microsoft/terminal/blob/02ac246807993e57dd5b6061bee1385f186ae20d/src/cascadia/TerminalControl/TermControl.cpp#L695-L696


`// ... cursorTimer.Start(); `

Uh, what did I do there...?

Fix patch:
diff --git a/src/cascadia/TerminalControl/TermControl.cpp b/src/cascadia/TerminalControl/TermControl.cpp
index 4f14aba020e..b6df41e3772 100644
--- a/src/cascadia/TerminalControl/TermControl.cpp
+++ b/src/cascadia/TerminalControl/TermControl.cpp
@@ -732,8 +732,16 @@ namespace winrt::Microsoft::Terminal::Control::implementation
             _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);
+            // the timer when the control is first focused.
+            //
+            // As of GH#11411, turn on the cursor if we've already been marked
+            // as focused. We suspect that it's possible for the Focused event
+            // to fire before the LayoutUpdated. In that case, the
+            // _GotFocusHandler would mark us _focused, but find that a
+            // _cursorTimer doesn't exist, and it would never turn on the
+            // cursor. To mitigate, we'll initialize the cursor's 'on' state
+            // with `_focused` here.
+            _core.CursorOn(_focused);
         }
         else
         {


Test patch: