Cannot type in new pane or tab until focus is manually activated with mouse click

[praimmugen]

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.

[lhecker]

I can't reproduce this issue, unless it's an initial launch of WSL. Does your issue happen with WSL or with any shell?

[praimmugen]

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

winterm-settings.json.zip

[jamesmcdonald]

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.

[elouanKeryell-Even]

same issue here, cannot seem to get the focus on a newly opened tab

[zadjii-msft]

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.

[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.

Unfortunately, pressing tab has no effect - I can't see anything getting focus no matter how many times I press the key.

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).

Not sure it changes things, but in my case focus is also lost when opening new WSL panes within a tab.

[zadjii-msft]

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

[praimmugen]

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.

[zadjii-msft]

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.

[matthuisman]

I have similar issue, but only using command prompt in terminal. Does not get focus. Need to click to allow typing Multiple laptops at my company have same issue - so it may be something they have installed...

[enlavin]

I'm experiencing a similar issue too, no matter if I use powershell, cmd or WSL. The window does not accept input and is not reacting to other window manager shortcuts like Win-Down/Win-Up to minimize/maximize the window. Alt-Space opens a context menu at the top-left of the active screen, if that's of any help. I have tried with and without Powertoys and the behavior is the same for me.

I have also identified 3 ways to restore the focus to the terminal window:

• Click inside with the mouse.
• Pin the terminal to the taskbar and use Win-Number to minimize/restore the window. Restoring the window focuses it.
• Try to close the window with Alt-F4. For some reason the window refocuses (it does not close) and then works as expected.

[jimmunn]

I see the exact behavior @enlavin reported, including the 3 ways to restore focus. It's pretty odd that alt-F4 doesn't close the app but does give my keyboard focus in the open tab. It seems like some other executable is getting focus and alt-F4 kills that executable and that sets focus to Terminal.

I am using Windows 10: 19044.1826 Windows Terminal Version: 1.14.1962.0 My default profile is Command Prompt

[kh185193]

I have been having the same issue for a while now. My default terminal is WSL (Ubuntu), but I see the same occur with Powershell and Command Prompt.

New windows and tabs have no focus before mouse click. After the mouse click I can alt+tab between that window and other applications with focus acting as expected. Creating a new tab on the now focused window will return the window to its unfocused state and require a further mouse click to regain it.

The only functions that seem to work on the new window (before focusing with a mouse click) are alt+f4 and minimising the window with win+down. win+up will not maximise the window when open, or re-open the window when recently minimised either.

Weirdly minimising the window with win+down then using alt+tab to open again gives the window focus again. New tabs in this window will work also. I may edit my terminal hotkey to do this for me in the meantime.

[codewzrd]

I'm experiencing the same behavior on version 1.14.2281.0. In my case, this applies to all profiles, Command Prompt, Powershell (pwsh), Ubuntu (WSL). None of the Windows keyboard shortcuts work for me.

When creating a new tab with any profile, the cursor does not blink till the tab gets focus.

I get focus in the new tab when i press Alt-F4.

[spootle]

Adding to the list of people with identical symptoms, with the added note that having acrylic material in the tab row enabled makes it more obvious that the entire Terminal app appears to lose focus (new tab makes the tab row go opaque, Alt+F4 kills the invisible window that is spawned at the top left of the window space and Terminal gets focus / tab row goes translucent

[hassec]

I have the problem on Windows 10 that opening a new terminal won't focus the terminal. But I also noticed the following that I though might be helpful:

using AutoHotkey's Window Spy when launching a new windows terminal instance I see it reporting that focus is on:

ahk_class PseudoConsoleWindow
ahk_exe OpenConsole.exe

So If I create a hotkey like this:

#t::
Run, wt.exe
WinWait, ahk_class PseudoConsoleWindow
WinClose, ahk_class PseudoConsoleWindow
Return

I can use Win + t to launch windows terminal and I can directly start typing as focus is correctly in the terminal because the PseudoConsoleWindow was closed.

[zadjii-msft]

🐉 HERE BE DRAGONS 🐉

I wouldn't do the above post(s) and close the PseudoConsoleWindow. That might just work for now as a workaround for this bug, but could lead to all sorts of weird behavior in the future. It might lead to crashes, or APIs not working right. I know in the past mingw has taken a dependency on that HWND's existence.

As much as it might seem like a viable workaround now, I'd much rather just fix the root cause, than have people try and close that window. I'm gonna collapse comments suggesting to do that for this reason. I don't know why yet the PseudoConsoleWindow is showing up as something that can steal focus (and even be closed in the first place!), but don't go closing it.

[telb99]

Having this same problem on one computer, not on another. v1.15.2524.0 Consistently works as expected on my personal computer, Windows 10 latest patches. Consistently needs manual focus with mouse click on the work computer, managed Windows 10.

The normal Windows keys to resize/move the main Terminal app do not work until I click it with the mouse. New Terminal windows, tabs, and panes opened within Terminal always need to be manually focused and its driving me nuts :)

[TVolden]

I have a similar problem on Windows 10 and Windows Terminal Version: 1.15.2874.0 When I open a new terminal window, the caret does not blink and it does not respond to keyboard input. It's not possible to open new tabs via hotkeys or to use the windows button to minimize/maximize the terminal window. CTRL+TAB to focus on the window does not help.

The problem can be fixed by mouse-clicking on the terminal window or by pressing the ALT+F4 hotkey. (The caret starts blinking and hotkeys work).

[mgrossmann]

Same problem with v1.15.2524.0

[zadjii-msft]

Lawds I can't repro this. We've got piles of reports, so this is definitely a real bug, but I can't get it to happen with any regularity.

Maybe it has something to do with DPI scaling?

Maybe there's something I can script up to insert in the powershell startup, to debug this? Theoretically, I can't have y'all click on the window to run commands, cause that would manually focus it (destroying the bad state we're curious about). But maybe there's something we can gather at the time the tab is created, automatically?

[zadjii-msft]

Wait is WSL installed and running when this repros? Maybe this is the WSLg thing, in secret? Does this happen every time the terminal launches? Maybe it's not the conpty window that's stealing foreground. How to check...

[matthuisman]

happens everytime when I launch terminal. I do have WSL installed

Opening any other shell also does not get focus until clicked

[spootle]

Wait is WSL installed and running when this repros?

If I open a powershell tab, run wsl --shutdown and open another powershell tab it still fails to get focus in the same way, if that helps.

[zadjii-msft]

Alright, a friend on the input team has an idea. For the folks that are hitting this consistently, we've got an idea how to debug. For this, you'll need InputCore.wprp from: https://gist.github.com/zadjii-msft/b67cc8946202593725f7ada64c6cb0c1

1. Grab that file and save it somewhere.
2. Open a conhost window (conhost.exe from the run dialog should work). (This might need to be run as admin, I forget)
3. In that window, run

   wpr -start path\to\InputCore.wprp
   

4. Open the terminal. Start typing. Obviously, the input won't go into the Terminal window, but the trace should capture who is getting it.
5. Switch back to the conhost window, and run

   wpr -stop input_trace.etl
   

6. Share that input_trace.etl file here.

This is basically a specific Feedback Hub trace, but without all the extra steps. I'll pass those along to @ekoschik, and hopefully we can get to the bottom of what's going on here.

[spootle]

6. Share that input_trace.etl file here.

input_trace.zip

[lbise]

input_trace.zip

There you go, when opening a WSL window.

[zadjii-msft]

Hokay, now I'm maybe asking too much here. Would anyone who's reproing this consistently be willing to check out the Terminal code, build main (just to validate that the issue is still happening on a dev build), then check out dev/migrie/b/13388-experiments-0, and see if the issue persists? Apparently, there's definitely a WM_ACTIVATE in the trace, on the hidden window (which should absolutely never really get brought to the FG).

The theory is that MA_NOACTIVATEANDEAT should prevent that? Again, I can't seem to repro the issue myself, which is why I'm asking for a little help here ☺️

[spootle]

Unfortunately I can't seem to get it to even build on my machine currently so it's going to be up to @lbise from the look of it

[lbise]

Looks like I can only reproduce at work and I will be off next week so it will have to wait a bit.