-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Comments
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. |
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. |
Well, that is... comprehensive. If you'd like to dig in further, I'm pretty sure the cursor blinker is set up here: terminal/src/cascadia/TerminalControl/TermControl.cpp Lines 684 to 702 in 02ac246
|
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"
}
}, |
terminal/src/cascadia/TerminalControl/TermControl.cpp Lines 695 to 696 in 02ac246
Uh, what did I do there...? |
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
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)
🎉This issue was addressed in #12094, which has now been successfully released as Handy links: |
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:
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.
The text was updated successfully, but these errors were encountered: