Cannot type in new pane or tab until focus is manually activated with mouse click #13388
Comments
praimmugen
added
the
Issue-Bug
ghost
added
Needs-Triage
praimmugen
changed the title
|
I can't reproduce this issue, unless it's an initial launch of WSL. Does your issue happen with WSL or with any shell? |
|
Hey, thanks for having a look at this. At the moment I can reproduce it with both WSL and Powershell profiles. However it's a lot less consistent than I thought initially. It doesn't make much sense, but mostly, after starting a new terminal, new tabs/panes are working fine (apart from the initial launch of WSL as you also noticed). However, if I switch to a different window for some time (seems like around a minute is enough, but 30 seconds is not), then go back to Windows Terminal (using Alt+Tab or mouse doesn't make a difference), I can experience the issue. At the moment the option "Automatically focus pane on mouse hover" is disabled, so I don't think that was necessarily making any difference like I said in the initial report. In case it helps, I'm attaching my settings.json |
|
I have an issue that might be related. If I open a terminal from the Start menu in Windows 11 by typing to search for "terminal", it almost always appears under other windows and fails to get focus. If I just click on the pinned icon in the Start menu without typing, this never happens. Opening a terminal with Win-x i also gets focus correctly, as does Ctrl-Shift-n from another terminal. This seems to be consistent with both Terminal (1.13.11432.0) and Terminal Preview (1.15.1863.0). My default profile is WSL, in case that makes a difference. The issue affects any new windows regardless of how many terminals I have open. |
|
same issue here, cannot seem to get the focus on a newly opened tab |
|
I'm gonna focus in on the PowerShell repro case here. The fact that the Terminal loses focus when a WSL tab is opened is a well-known bug (I believe in WSLg). I don't have any idea why this would happen. @praimmugen when the terminal does get into this state (where apparently nothig is focused), what does pressing tab do? That should move focus to the "next" UI element, which might help us figure out where focus is currently. |
zadjii-msft
added
the
Needs-Author-Feedback
Unfortunately, pressing
Not sure it changes things, but in my case focus is also lost when opening new WSL panes within a tab. |
ghost
added
Needs-Attention
|
Is there anything in your PowerShell profile? If pressing tab does nothing, then I'd suspect that maybe the Terminal HWND itself doesn't even have focus, and something else is the forground window. Maybe there's something in your profile.ps1 that's like, shelling out to WSL or something |
zadjii-msft
added
Needs-Author-Feedback
|
Nothing in my PS profile, it's completely empty. Long shot, but I also tried stopping a few apps that were running in background (things like AltDrag, AutoHotkey scripts, X server and several others), but unfortunately it didn't help. |
ghost
added
Needs-Attention
|
I WONDER. I wonder if this is another facet of #13589. Like, if the WS_TOOLWINDOW created by conpty becomes the foreground window for some reason? It absolutely never should, it's not visible but... clearly there's something weird happening. Maybe this is a clue as to why on Windows 10 the taskbar seems to think that it should restore the hidden window first. Maybe that's why we can't repro this either, we're checking on Windows 11. Hmm. NOTE TO SELF: Assigning to myself to investigate on the Win10 VM to see if I can't repro this. Also use as an opportunity to double check the taskbar code, and see what heuristic they're using, and why it thinks the conpty window is the one it should operate on. |
zadjii-msft
added
Product-Terminal
zadjii-msft
removed
Needs-Triage
|
I have similar issue, but only using command prompt in terminal. |
|
Please fix this. It is infuriating and causes me lots of failed logins etc. As you can never rely on terminal retaining focus as you are typing. |
|
|
At it appears this is an interaction between Windows Terminal (reproducible with 1.20.11781.0) and BeyondTrust (reproducible with BeyondTrust Client version 23.9.225.0, PMC adapter 23.9.578) on Windows 11 Enterprise (10.0.22621 Build 22621), is it possible that the Terminal team can assemble an equivalent environment to get a repro, and work with BeyondTrust dev team to determine what might be going on here and find a solution? |
|
I don't have BeyondTrust, I don't have any shitty bloatware installed, I even reformatted my computer since I had this issue, and it's still there, on a fresh windows 11 install. The only "exotic" stuff I have installed is WSL 2.0 |
This comment was marked as off-topic.
This comment was marked as off-topic.
Worked with @ekoschik on this one. ## Bug the first: the MSAL window `ixptools` spawns > The auth prompt in pwsh.exe is disabling the terminal window while its opened and re-enabling it when the window closes. BUT it is enabling Terminal after dismissing itself, instead of before, which means terminal is disabled when activated. > > Terminal wants focus on the ISLAND window (a grandchild; island is parented to bridge, which is parented to terminal’s TLW). When it is activated, it gets a `WM_SETFOCUS` (in response to DefWindowProc `WM_ACTIVATE`). From `WM_SETFOCUS` it calls `SetFocus` on the bridge window, and similarly the bridge calls `SetFocus` on the island. > > If the TLW is disabled, these `SetFocus` calls fail (see [this check](#internal-link-redacted) in `SetFocus`). In the case above, this leaves Terminal’s TLW as focus, and it doesn’t handle keyboard input. Note that the window IS foreground/active, but because focus is not on the island it doesn’t see the keyboard input. Another thing to note is that clicking on the space to the right of the tabs does NOT revive keyboard input, but clicking on the tabs or main area does. > **I recommend having the TLW handle WM_ENABLE and call SetFocus on the island window.** And guess what, that works! ## Bug the second: When sublime text is the git `EDITOR`, it doesn't toss focus back to the Terminal > In this case, Sublime is calling SFW on the pseudo console window. I don’t have its code, but it is presumably doing something like SetForegroundWindow(GetConsoleWindow()). This queues an event to the pseudo window, and when that event is processed the pseudo window becomes the active and focus window on the queue (which is shared with Terminal). > > The sublime window dismisses itself and does the above SFW call. Dismissing immediately activates the Terminal TLW, which does the triple-focus dance (TLW sets focus on itself, then bridge, then island). This completes but is overwritten immediately when the pseudo window activates itself. Note that the pseudo window is active at this point (not the terminal window). > **I recommend having the Pseudo console window handle WM_ACTIVATE by calling SetFocus on the island window (and not passing the message to DefWindowProc).** And guess what, that works! ---- Closes #15956 (I did test this) This might be related to #13388, we'll have folks try canary and check
|
@NinoDLC FWIW there's a known issue in WSLg that causes the wslg interop to steal focus from the terminal whenever WSL starts up. This thread is specifically for the mysterious sources of focus being lost that don't involve WSL spawning. |
|
We merged in a fix that we think is tangential to this problem over in #17828 just today. It should be in this evening's Canary build. Tomorrow, could someone who was seeing the non-WSL focus lost issue test out Canary with a version greater than You can grab terminal canary from https://aka.ms/terminal-canary-installer (we'll all be out for the long weekend, so I won't actually know the next canary's build number till like Tuesday) |
|
I'd be happy to. Will do it tomorrow. |
|
I have just tested the Canary version (1.23.2421.0) and it looks very good! 🎉 There STILL IS some focus loss, but it is very short (blink of an eye, literally) and focus immediately returns back to the WT. If that temporary focus loss is long enough to interfere with input - this I cannot tell. But definitely there is a great step forward! 💪 The temporary focus loss is manifested by the mouse cursor re-appearing on the screen (after it has disappeared on keyboard input) and if you use e.g. a red window background for inactive WT window - you can see it blink. This happens ~30 seconds after WT launch/new tab opened too. |
|
I'm super glad to hear it!
That sounds telltale like some other application is opening for an imperceivable amount of time, then immediately closing. We basically found a slower version of this that involved a git MSAL authentication prompt. That was a clearer example to trace of "another window appears briefly, then closes itself". I doubt whatever is spawning on your machine is an MSAL prompt, but I bet the side effects are similar. We probably won't be able to do anything about that <1s gap where another window opens into the FG and steals focus, but this at least feels like it'll no longer be blocking for folks. |
|
I will check it again with the script to detect focus-thief used in the past and let you know.
|
|
Tested with script from #13388 (comment) It seems it is the same story, where the focus is lost for the shell process that was started in the WT (pwsh in this case), but that happens for much <1s as can be seen above and focus goes immediately back to the WT itself. |
|
That back-and-forth focus tossing is exactly what I was hoping to address with #17829. We'll probably merge that next week and see if that fixes the remaining issues. |
|
In my case, Terminal works just fine until I open the Outlook Office 365 Client. I can navigate panes using keyboard shortcuts like |
|
I just tested the canary build and it is certainly a large improvement.
Focus does appear to be lost still (the mouse cursor becomes suddenly
visible), but it returns automatically now where before it would not return
without clicking on the terminal. Ideally focus wouldn't be lost at
all...but this is better -- continuing to type hides the mouse cursor again
and no clicking is needed.
Some noteworthy info:
I am in a corporate environment, running Windows 11 Enterprise 22H2
BeyondTrust Privilege Management is installed
In both Terminal builds (canary and 1.20.11781.0) focus is lost
approximately 35 seconds after opening a new tab
I can type characters one at a time, approximately one second apart and
focus is always lost after 35 seconds or so.
I was not using WSL at the time, just launching a new tab running git bash.
Thank you for working on this issue, it is maddening!
…On Fri, Aug 30, 2024 at 8:01 AM Adam Purcell ***@***.***> wrote:
In my case, Terminal works just fine until I open the Outlook Office 365
Client. I can navigate panes using keyboard shortcuts like Alt + Up / Down
but can't select with mouse. Toolbar buttons are also disabled. When I
close Outlook, it works just fine again. I also tried the Canary release
mentioned above with the same results. I'm using the Outlook web client as
a workaround.
OS Name: Microsoft Windows 11 Enterprise
OS Version: 10.0.22631 N/A Build 22631
—
Reply to this email directly, view it on GitHub
<#13388 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEVIQPEHMTTUT6VW77N2GDZUBUKRAVCNFSM5Z6SZ2F2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZSGEYTOOJRGU2Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
It works. It still loses focus for a split second and comes back. If you keep typing when this happens you might loose a character, Other than that, excellent job. Finally, I will shift to Terminal completely . Tested on win 10 enterprise 22H2 with beyondTrust and using gitbash for testing |
Worked with @ekoschik on this one. ## Bug the first: the MSAL window `ixptools` spawns > The auth prompt in pwsh.exe is disabling the terminal window while its opened and re-enabling it when the window closes. BUT it is enabling Terminal after dismissing itself, instead of before, which means terminal is disabled when activated. > > Terminal wants focus on the ISLAND window (a grandchild; island is parented to bridge, which is parented to terminal’s TLW). When it is activated, it gets a `WM_SETFOCUS` (in response to DefWindowProc `WM_ACTIVATE`). From `WM_SETFOCUS` it calls `SetFocus` on the bridge window, and similarly the bridge calls `SetFocus` on the island. > > If the TLW is disabled, these `SetFocus` calls fail (see [this check](#internal-link-redacted) in `SetFocus`). In the case above, this leaves Terminal’s TLW as focus, and it doesn’t handle keyboard input. Note that the window IS foreground/active, but because focus is not on the island it doesn’t see the keyboard input. Another thing to note is that clicking on the space to the right of the tabs does NOT revive keyboard input, but clicking on the tabs or main area does. > **I recommend having the TLW handle WM_ENABLE and call SetFocus on the island window.** And guess what, that works! ## Bug the second: When sublime text is the git `EDITOR`, it doesn't toss focus back to the Terminal > In this case, Sublime is calling SFW on the pseudo console window. I don’t have its code, but it is presumably doing something like SetForegroundWindow(GetConsoleWindow()). This queues an event to the pseudo window, and when that event is processed the pseudo window becomes the active and focus window on the queue (which is shared with Terminal). > > The sublime window dismisses itself and does the above SFW call. Dismissing immediately activates the Terminal TLW, which does the triple-focus dance (TLW sets focus on itself, then bridge, then island). This completes but is overwritten immediately when the pseudo window activates itself. Note that the pseudo window is active at this point (not the terminal window). > **I recommend having the Pseudo console window handle WM_ACTIVATE by calling SetFocus on the island window (and not passing the message to DefWindowProc).** And guess what, that works! ---- Closes #15956 (I did test this) This might be related to #13388, we'll have folks try canary and check (cherry picked from commit 17a55da) Service-Card-Id: PVTI_lADOAF3p4s4AmhmQzgSwIkE Service-Version: 1.22
zadjii-msft
added
the
Resolution-Fix-Committed
Worked with @ekoschik on this one. ## Bug the first: the MSAL window `ixptools` spawns > The auth prompt in pwsh.exe is disabling the terminal window while its opened and re-enabling it when the window closes. BUT it is enabling Terminal after dismissing itself, instead of before, which means terminal is disabled when activated. > > Terminal wants focus on the ISLAND window (a grandchild; island is parented to bridge, which is parented to terminal’s TLW). When it is activated, it gets a `WM_SETFOCUS` (in response to DefWindowProc `WM_ACTIVATE`). From `WM_SETFOCUS` it calls `SetFocus` on the bridge window, and similarly the bridge calls `SetFocus` on the island. > > If the TLW is disabled, these `SetFocus` calls fail (see [this check](#internal-link-redacted) in `SetFocus`). In the case above, this leaves Terminal’s TLW as focus, and it doesn’t handle keyboard input. Note that the window IS foreground/active, but because focus is not on the island it doesn’t see the keyboard input. Another thing to note is that clicking on the space to the right of the tabs does NOT revive keyboard input, but clicking on the tabs or main area does. > **I recommend having the TLW handle WM_ENABLE and call SetFocus on the island window.** And guess what, that works! ## Bug the second: When sublime text is the git `EDITOR`, it doesn't toss focus back to the Terminal > In this case, Sublime is calling SFW on the pseudo console window. I don’t have its code, but it is presumably doing something like SetForegroundWindow(GetConsoleWindow()). This queues an event to the pseudo window, and when that event is processed the pseudo window becomes the active and focus window on the queue (which is shared with Terminal). > > The sublime window dismisses itself and does the above SFW call. Dismissing immediately activates the Terminal TLW, which does the triple-focus dance (TLW sets focus on itself, then bridge, then island). This completes but is overwritten immediately when the pseudo window activates itself. Note that the pseudo window is active at this point (not the terminal window). > **I recommend having the Pseudo console window handle WM_ACTIVATE by calling SetFocus on the island window (and not passing the message to DefWindowProc).** And guess what, that works! ---- Closes #15956 (I did test this) This might be related to #13388, we'll have folks try canary and check (cherry picked from commit 17a55da) Service-Card-Id: PVTI_lADOAF3p4s4AmhmszgSwIkA Service-Version: 1.21
|
We were happy a bit too soon - there's another scenario we did not test: start Windows Terminal (or a new tab), switch to some other application and wait. This time WT steals focus and all the input goes to the WT console. Which is dangerous (e.g. when typing password, or the "rm -rf /foo/bar" command in the other window or app). See the output from the PowerShell script (already used in the previous comments) below. Test steps taken - with the script started in the stand-alone Windows PowerShell window, i.e.: not in WT:
Unfortunately this new behaviour is even more annoying (and dangerous) than the old one... EDIT: The initial WT handle and process provided above do not refer to WT; they were for the standalone PowerShell window. I have removed (xxxx) them not to cause confusion. |
This comment has been minimized.
This comment has been minimized.
|
On Windows 11 I can still observe the focus theft with the latest WT (1.21.2911.0) |
|
@zadjii-msft - shall the previous behaviour of focus loss be |
and others
Windows Terminal version
1.14.1451.0
Windows build number
10.0.19042.0
Other Software
No response
Steps to reproduce
Create new pane/new tab
Expected Behavior
It is possible to type in the newly opened terminal
Actual Behavior
Unable to type until I click on the new terminal.
Note that enabling the option "Automatically focus pane on mouse hover" partially prevents the issue from happening.
It seems like focus is removed from all terminal tabs/panes whenever a new one is created.
The text was updated successfully, but these errors were encountered: