starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

TabSwitcher stay on top and I need to click on the window to be able to type anything #11477

New Issue
Closed
opened 2026-01-31 02:48:42 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 02:48:42 +00:00
Owner
Copy Link

Originally created by @Nordes on GitHub (Nov 18, 2020).

Environment

Platform ServicePack Version VersionString

Win32NT 10.0.19042.0 Microsoft Windows NT 10.0.19042.0

Windows Terminal - Version: 1.4.3141.0

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):

Any other software?

Steps to reproduce

When doing tabbing, it sometimes happens:

  • Ctrl+Tab (basically sometime randomly)

Expected behavior

Switch tab without having the tabswitcher overlay staying on top

Actual behavior

The tabswitcher stay stuck on top (overlay) and I am not able to type anything. Even when I hit escape key, it does not disable the tab switcher. It requires me to do a mouse click. You can see on below picture that the focus is lost from the terminal (no caret flashing)

image

Originally created by @Nordes on GitHub (Nov 18, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment Platform ServicePack Version VersionString -------- ----------- ------- ------------- Win32NT 10.0.19042.0 Microsoft Windows NT 10.0.19042.0 Windows Terminal - Version: 1.4.3141.0 ```none Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd] Windows Terminal version (if applicable): Any other software? ``` # Steps to reproduce When doing tabbing, it sometimes happens: - Ctrl+Tab (basically sometime randomly) <!-- A description of how to trigger this bug. --> # Expected behavior Switch tab without having the tabswitcher overlay staying on top <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior The tabswitcher stay stuck on top (overlay) and I am not able to type anything. Even when I hit escape key, it does not disable the tab switcher. It requires me to do a mouse click. You can see on below picture that the focus is lost from the terminal (no caret flashing) ![image](https://user-images.githubusercontent.com/446572/99546992-0703a280-2985-11eb-8d10-480016b08e68.png) <!-- What's actually happening? -->
claunia commented 2026-01-31 02:48:43 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 18, 2020):

The tab switcher should dismiss itself when the ctrl key is released, does it not? If it doesn't, what keyboard layout are you using? And are you perhaps using Sticky Keys?

(For the record, you can disable the tab switcher entirely with "useTabSwitcher": false in the root of your settings)

@zadjii-msft commented on GitHub (Nov 18, 2020): The tab switcher _should_ dismiss itself when the <kbd>ctrl</kbd> key is released, does it not? If it doesn't, what keyboard layout are you using? And are you perhaps using Sticky Keys? (For the record, you can disable the tab switcher entirely with `"useTabSwitcher": false` in the root of your settings)
claunia commented 2026-01-31 02:48:43 +00:00
Author
Owner
Copy Link

@Nordes commented on GitHub (Nov 18, 2020):

The keyboard I use is the Logi MX Keys (Logitech wireless keyboard). Also, the sticky key is off in my windows settings.

The "ctrl+tab" key usually works, but it happens "sometimes" that the overlay with the tab names remains there. It happened to me a few times already, but it's not like it's every time.

For now, I will disable the tabswitcher for now. Thank's for giving the option.

@Nordes commented on GitHub (Nov 18, 2020): The keyboard I use is the **Logi MX Keys** (Logitech wireless keyboard). Also, the sticky key is off in my windows settings. The "ctrl+tab" key usually works, but it happens "sometimes" that the overlay with the tab names remains there. It happened to me a few times already, but it's not like it's every time. For now, I will disable the tabswitcher for now. Thank's for giving the option.
claunia commented 2026-01-31 02:48:44 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 20, 2020):

@Don-Vito do you think this is related to the fix you made earlier?

@DHowett commented on GitHub (Nov 20, 2020): @Don-Vito do you think this is related to the fix you made earlier?
claunia commented 2026-01-31 02:48:44 +00:00
Author
Owner
Copy Link

@Don-Vito commented on GitHub (Nov 20, 2020):

@DHowett - my fix was only for custom bindings, so I guess it is something else.

@Don-Vito commented on GitHub (Nov 20, 2020): @DHowett - my fix was only for custom bindings, so I guess it is something else.
claunia commented 2026-01-31 02:48:44 +00:00
Author
Owner
Copy Link

@electronic-dk commented on GitHub (Nov 20, 2020):

I've also faced this issue several times on a dell 7400 laptop. I have English (US) and Russian layouts on the keyboard, but I couldn't pinpoint anything specific that causes such behavior.

@electronic-dk commented on GitHub (Nov 20, 2020): I've also faced this issue several times on a dell 7400 laptop. I have English (US) and Russian layouts on the keyboard, but I couldn't pinpoint anything specific that causes such behavior.
claunia commented 2026-01-31 02:48:44 +00:00
Author
Owner
Copy Link

@Don-Vito commented on GitHub (Nov 20, 2020):

@electronic-dk - few questions:

  1. does it happen to you in the same version of Terminal as in the original post?
  2. Does it happen randomly or you can reproduce it?
  3. Are you using Ctrl+Tab or some custom binding.
  4. Does it happen if you are holding Ctrl for a while or it happens even for a single navigation
  5. Is it always happening for the last tab or any specific tab?
@Don-Vito commented on GitHub (Nov 20, 2020): @electronic-dk - few questions: 1. does it happen to you in the same version of Terminal as in the original post? 2. Does it happen randomly or you can reproduce it? 3. Are you using Ctrl+Tab or some custom binding. 4. Does it happen if you are holding Ctrl for a while or it happens even for a single navigation 5. Is it always happening for the last tab or any specific tab?
claunia commented 2026-01-31 02:48:45 +00:00
Author
Owner
Copy Link

@electronic-dk commented on GitHub (Nov 20, 2020):

@Don-Vito

  1. The version is the same Version: 1.4.3141.0 I don't think I've seen this issue before the 1.4 update
  2. It's been happening randomly. Unfortunately, I don't have a reliable way of reproducing it at the moment, I'll keep experimenting and let you know if I can reproduce the issue reliably. I noticed that a somewhat reproducible way to get the tab switcher to stuck is to open 3 - 4 tabs, switch between then several times quickly, then close all the tabs but one, open a new tab and try to switch to the previous tab. The content of the tabs seems unimportant since I was able to reproduce it with both powershell and ubuntu in WSL2 tabs.
  3. I'm using the default Ctrl+Tab binding
  4. I'm pretty sure it happens for single navigations as well
  5. I don't think it's been happening for any specific tab

In general, it seems that the tab switcher gets stuck after I make several quick changes between tabs, the next switch after that sometimes is stuck.
Sorry for the somewhat vague description, I'd love to give you a more elaborate explanation, but I don't have any :(
Please, let me know if I can give you any more info.

@electronic-dk commented on GitHub (Nov 20, 2020): @Don-Vito 1. The version is the same Version: 1.4.3141.0 I don't think I've seen this issue before the 1.4 update 2. It's been happening randomly. Unfortunately, I don't have a reliable way of reproducing it at the moment, I'll keep experimenting and let you know if I can reproduce the issue reliably. I noticed that a somewhat reproducible way to get the tab switcher to stuck is to open 3 - 4 tabs, switch between then several times quickly, then close all the tabs but one, open a new tab and try to switch to the previous tab. The content of the tabs seems unimportant since I was able to reproduce it with both powershell and ubuntu in WSL2 tabs. 3. I'm using the default Ctrl+Tab binding 4. I'm pretty sure it happens for single navigations as well 5. I don't think it's been happening for any specific tab In general, it seems that the tab switcher gets stuck after I make several quick changes between tabs, the next switch after that sometimes is stuck. Sorry for the somewhat vague description, I'd love to give you a more elaborate explanation, but I don't have any :( Please, let me know if I can give you any more info.
claunia commented 2026-01-31 02:48:45 +00:00
Author
Owner
Copy Link

@Don-Vito commented on GitHub (Nov 20, 2020):

@Don-Vito

  1. The version is the same Version: 1.4.3141.0 I don't think I've seen this issue before the 1.4 update
  2. It's been happening randomly. Unfortunately, I don't have a reliable way of reproducing it at the moment, I'll keep experimenting and let you know if I can reproduce the issue reliably. I noticed that a somewhat reproducible way to get the tab switcher to stuck is to open 3 - 4 tabs, switch between then several times quickly, then close all the tabs but one, open a new tab and try to switch to the previous tab. The content of the tabs seems unimportant since I was able to reproduce it with both powershell and ubuntu in WSL2 tabs.
  3. I'm using the default Ctrl+Tab binding
  4. I'm pretty sure it happens for single navigations as well
  5. I don't think it's been happening for any specific tab

In general, it seems that the tab switcher gets stuck after I make several quick changes between tabs, the next switch after that sometimes is stuck.
Sorry for the somewhat vague description, I'd love to give you a more elaborate explanation, but I don't have any :(
Please, let me know if I can give you any more

Thanks! Your description is very insightful. Especially the fact that a prior fast modification triggers this defect more often. It can be a strong indicator for some sort of race condition between the switcher and the tabs row. I will try to reproduce again, but this time with your hints.

@Don-Vito commented on GitHub (Nov 20, 2020): > @Don-Vito > > 1. The version is the same Version: 1.4.3141.0 I don't think I've seen this issue before the 1.4 update > 2. It's been happening randomly. Unfortunately, I don't have a reliable way of reproducing it at the moment, I'll keep experimenting and let you know if I can reproduce the issue reliably. I noticed that a somewhat reproducible way to get the tab switcher to stuck is to open 3 - 4 tabs, switch between then several times quickly, then close all the tabs but one, open a new tab and try to switch to the previous tab. The content of the tabs seems unimportant since I was able to reproduce it with both powershell and ubuntu in WSL2 tabs. > 3. I'm using the default Ctrl+Tab binding > 4. I'm pretty sure it happens for single navigations as well > 5. I don't think it's been happening for any specific tab > > In general, it seems that the tab switcher gets stuck after I make several quick changes between tabs, the next switch after that sometimes is stuck. > Sorry for the somewhat vague description, I'd love to give you a more elaborate explanation, but I don't have any :( > Please, let me know if I can give you any more Thanks! Your description is very insightful. Especially the fact that a prior fast modification triggers this defect more often. It can be a strong indicator for some sort of race condition between the switcher and the tabs row. I will try to reproduce again, but this time with your hints.
claunia commented 2026-01-31 02:48:45 +00:00
Author
Owner
Copy Link

@Don-Vito commented on GitHub (Nov 20, 2020):

@electronic-dk - updating that thanks to you hints I was able to reproduce it in a release version, but debugging the release with windbg is not of much fun. Trying to reproduce it with dev version.

@Don-Vito commented on GitHub (Nov 20, 2020): @electronic-dk - updating that thanks to you hints I was able to reproduce it in a release version, but debugging the release with windbg is not of much fun. Trying to reproduce it with dev version.
claunia commented 2026-01-31 02:48:45 +00:00
Author
Owner
Copy Link

@Don-Vito commented on GitHub (Nov 20, 2020):

So... I am only 90% sure if it is exactly the same, but I was able to deterministically reproduce a significant issue with tab creation / closing while tab switcher is open for a while.

I know that in the original issue the tab switcher does not remain open for a long time, but I believe it can still be related due to the asynchronous nature of tab creation / deletion. I mean in this case it must be a race between tab switcher being open and the async logic of tab closing applied.

So here how it goes:
PaletteLostFocus

@zadjii-msft - actually when the third tab is open I also don't need to hold ctrl anymore. Probably because the focus is somewhere else. Any reason we don't always close palette when the focus is lost?

@Don-Vito commented on GitHub (Nov 20, 2020): So... I am only 90% sure if it is exactly the same, but I was able to deterministically reproduce a significant issue with tab creation / closing while tab switcher is open for a while. I know that in the original issue the tab switcher does not remain open for a long time, but I believe it can still be related due to the asynchronous nature of tab creation / deletion. I mean in this case it must be a race between tab switcher being open and the async logic of tab closing applied. So here how it goes: ![PaletteLostFocus](https://user-images.githubusercontent.com/4639110/99821038-31f31f80-2b5a-11eb-951b-eb107b00bade.gif) @zadjii-msft - actually when the third tab is open I also don't need to hold ctrl anymore. Probably because the focus is somewhere else. Any reason we don't always close palette when the focus is lost?
claunia commented 2026-01-31 02:48:46 +00:00
Author
Owner
Copy Link

@Don-Vito commented on GitHub (Dec 9, 2020):

@DHowett - Now that #8355 is merged this hopefully should be resolved as well. Even in the race scenario, the switcher will be either focused and navigable or unfocused and collapsed.

@Don-Vito commented on GitHub (Dec 9, 2020): @DHowett - Now that #8355 is merged this hopefully should be resolved as well. Even in the race scenario, the switcher will be either focused and navigable or unfocused and collapsed.
claunia commented 2026-01-31 02:48:46 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 11, 2020):

Fingers crossed!

@DHowett commented on GitHub (Dec 11, 2020): Fingers crossed!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Help Wanted Issue-Bug Priority-2 Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11477
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?