Active terminal does not get focus when window gets focus #522
Comments
|
Where specifically are you clicking to focus the window? I'm seeing that clicking in the main part of the terminal window (with the text) works to send focus, but clicking anywhere in the tab row does not focus the terminal control |
zadjii-msft
added
the
Needs-Repro
|
@zadjii-msft Yes. I realized it only occurs when clicking the tab row. However, is this by design? Btw, before I forget; I really love what you're doing with this project! The Windows Terminal is super fast! |
|
That's good to know! Makes fixing it a lot easier. It's definitely not by design, I just need to know what UI element we need to eat the focus from :P Thanks for the kind words! We're really happy to be able to make this for the community (and ourselves :P) |
|
Found a few scenarios to lose focus (I suspect these to be basically the same problem):
|
miniksa
added
Issue-Bug
miniksa
added
Area-Interaction
|
This also happens with When the Terminal regains focus by either clicking the title bar, any tab or the app icon in the task bar, then only the window is focused, not the active terminal, preventing you to type text into it. |
|
Hey wadda ya know, this might just be related to #1205, which I just started on this morning. I'll make sure to include these scenarios in my investigations. |
If I want to double up and also fix #522 (which I do), then I need to also * when a tab GetsFocus, send the focus instead to the Pane * When the border is clicked on, focus that pane's control And like a lot of cleanup, because this is horrifying
|
Moved to Windows terminal this week, loving it, but this is my biggest user-experience issue. I need to retrain my brain. Windows has trained me the safe way to focus any command window is by clicking the title-bar then the cursor will be in the correct place so i can type. I've typed so many characters into the ether this week |
ghost
added
Needs-Tag-Fix
## Summary of the Pull Request Unties the concept of "focused control" from "active control". Previously, we were exclusively using the "Focused" state of `TermControl`s to determine which one was active. This was fraught with gotchas - if anything else became focused, then suddenly there was _no_ pane focused in the Tab. This happened especially frequently if the user clicked on a tab to focus the window. Furthermore, in experimental branches with more UI added to the Terminal (such as [dev/migrie/f/2046-command-palette](https://github.com/microsoft/terminal/tree/dev/migrie/f/2046-command-palette)), when these UIs were added to the Terminal, they'd take focus, which again meant that there was no focused pane. This fixes these issue by having each Tab manually track which Pane is active in that tab. The Tab is now the arbiter of who in the tree is "active". Panes still track this state, for them to be able to MoveFocus appropriately. It also contains a related fix to prevent the tab separator from stealing focus from the TermControl. This required us to set the color of the un-focused Pane border to some color other that Transparent, so I went with the TabViewBackground. Panes now look like the following:  ## References See also: #2046 ## PR Checklist * [x] Closes #1205 * [x] Closes #522 * [x] Closes #999 * [x] I work here * [😢] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed Tested manually opening panes, closing panes, clicking around panes, the whole dance. --------------------------------------------------- * this is janky but is close for some reason? * This is _almost_ right to solve #1205 If I want to double up and also fix #522 (which I do), then I need to also * when a tab GetsFocus, send the focus instead to the Pane * When the border is clicked on, focus that pane's control And like a lot of cleanup, because this is horrifying * hey this autorevoker is really nice * Encapsulate Pane::pfnGotFocus * Propogate the events back up on close * Encapsulate Tab::pfnFocusChanged, and clean up TerminalPage a bit * Mostly just code cleanup, commenting * This works to hittest on the borders If the border is `Transparent`, then it can't hittest for Tapped events, and it'll fall through (to someone) THis at least works, but looks garish * Match the pane border to the TabViewHeader * Fix a bit of dead code and a bad copy-pasta * This _works_ to use a winrt event, but it's dirty * Clean up everything from the winrt::event debacle. * This is dead code that shouldn't have been there * Turn Tab's callback into a winrt::event as well
|
🎉This issue was addressed in #3540, which has now been successfully released as Handy links: |
|
I'm still experiencing this issue. Exactly as described here and in #3609. Just switched to terminal hoping to make it my main, but this is really messing with me. My version: I'm on 1903 (Build 18362.535) |
|
Confirming that it's still happening for me as well. Looks like issue #3609 is still open and addressing this problem. |
|
I have version 1.15.2712.0 and opening a new tab (Ctrl+Shift+T ) does not gain focus until clicked on the window area. |
|
Problem persists in version 1.15.2874.0 |
|
If you're seeing this on 1.15+, you're probably seeing #13388, not this thread. I'm gonna lock this thread as out-of-date. The root cause here was addressed a couple years ago. Let's track the new regression in the new thread. Thanks! |
Your Windows build number:
10.0.18362.86
What you're doing and what's happening:
What's wrong / what should be happening instead:
Input should be sent to the active console.
The text was updated successfully, but these errors were encountered: