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?
When doing tabbing, it sometimes happens:
Switch tab without having the tabswitcher overlay staying on top
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)

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)
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.
@Don-Vito do you think this is related to the fix you made earlier?
@DHowett - my fix was only for custom bindings, so I guess it is something else.
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 - few questions:
@Don-Vito
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.
@Don-Vito
- The version is the same Version: 1.4.3141.0 I don't think I've seen this issue before the 1.4 update
- 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.
- I'm using the default Ctrl+Tab binding
- I'm pretty sure it happens for single navigations as well
- 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.
@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.
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:

@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?