This is super weird. I bet it has to do with our WM_NCHITTEST code in NonClientIslandWindow. If I had to go out on a limb, it's almost as if the entire titlebar area is being treated as HTTOP, which would cause the area to be treated as the "top drag region".

Unfortunately, I can't really repro this myself :/

@Ronkiro if you click and drag while the mouse is like that, does it resize the window? If so, that would probably confirm my suspicion. Also, does it act like that for the entire height of the titlebar area?

P.S.

protip: you can actually just paste images directly into the input box on github, and it'll automatically uplod them to github and embed them inline. It's pretty neat

@zadjii-msft
I tried adding the image but it was failing... It was creating github's link but it was a wrong link lol i think i was missing something.

Back to the terminal, holding click doesn't resizes window. But, when moving to the non-button area of the title bar (The middle area) the cursor goes to default one again.

Still in the default cursor, i can't click close/minimize/etc. ALT+F4 works though.
Testing a bit, i also noticed that i cannot do any mouse actions in terminal (Like marking a text, right clicking to paste/open menu, etc). But shortcuts like CTRL+V works. The only exceptions are double clicking the middle area (it maximizes the screen properly) and resizing the window.

Also, the image the cursor sticks with is the last one i hovered. I mean, if i move to the "Resize left" area and then move to title bar, the mouse will be with the "Resize left" icon.

I also had this issue (Microsoft Windows [Version 10.0.18362.418]), but restarting the machine fixed it.

@Ronkiro Does restarting fix it for you? @JohnFNovak indicates that it may. :smile:

Nope @DHowett-MSFT. I mean, i already had restarted many times until i really create the issue here, but it didn't help.

Also noting that it's an enterprise W10, not sure if this can help anyhow.

this happens to me randomly too, exiting powertoys process seems to fix it.
in a related problem trying to drag the wt window with shift pressed freeze the window in place
but it start moving when you release the shift key

Seems related to PowerToys for me too, exiting also fixed.

Excellent to hear. Summoning @crutkas if he's got any ideas on the matter

What version of PowerToys are you on

I'm trying to repo this but can't. I'm on PowerToys 0.14.1 and here are my steps to reproduce. You may need to share your FancyZone settings.

We do stuff with shift to make you aware we're going to snap to your zones.

My system info currently:

• PowerToys 0.14.1
• Terminal: 0.7.3451.0
• Win10: 18363.535, Version 1909

1. Launch power toys.
2. Launch Terminal.
3. click minimize, maximize (they all work)
4. added PowerShell tab
5. Added Cmd Tab
6. Remove new PowerShell tab with X
7. Hold Shift and go to FancyZone zone

Win10: Ver 1903, build 18362.295 (Enterprise)
PowerToys: 0.11.0

I also have "Use new zone editting experience" enabled, not sure if this has any relationships.

BTW, i can't reproduce the problem again now. Would be good if anyone that also had the problem could keep helping with info. But i didn't change any of the versions, just did the workaround fix.

powertoys 0.14.1
win10 insider slow ring : 2004, build 19041.1
wt:0.7.3451.0

the bug happened when i was collecting the version of wt,
it also seen to affect the power toys settings
i connected a display and moving wt window to it made the buttons work
though only on the 2nd display
used the step recorder to capture it:
powertoys bug.zip
powertoys bug 2.zip

so any news on this?

I can recreate this but i think it is with the terminal as i can repo this behavior with PowerToys fully off. Note this is the only way i can recreate this.

I'm on Terminal 0.8.10091.0

What i'm doing to recreate

1. launch terminal
2. Left-Click on title bar
3. Hold shift
4. Drag mouse downward and into the console screen itself
5. Release mouse

Actual behavior:
Window freezes for about 3 seconds, can't drag it or min/max/close buttons won't respond to clicking or hovering as well

Window freezes for about 3 seconds, can't drag it or min/max/close buttons won't respond to clicking or hovering as well

does the buttons on the window stay unresponsive when you release shift?

I can recreate this but i think it is with the terminal as i can repo this behavior with PowerToys fully off

but when the bug happens the powertoys settings is also affected

Yes, window is unresponsive but comes back after about three seconds. The fact I can do this without PT running means something is going on with terminal, not PT.

Step recorder was helpful but a bit confusing due to everything was in Portuguese and hand to be manually translated. For showing unresponsive stuff, a video may be more impactful here. Gamebar (win+g) can do this.

So if what my steps to cause a freeze is a different thing, please let’s do the step by step.

everything was in Portuguese

sorry about that, I should have tried harder to edit the file so i could translate it.

Gamebar (win+g) can do this.

yeah but it only captures the window not the whole screen. will try it when it happens again if it is going to be helpful

Yes, window is unresponsive but comes back after about three seconds
running means something is going on with terminal, not PT.

i reported that behavior here #3325(comment)

@LuanVSO

1. never be sorry for having something in your native language.
2. if you could do a step by step like i did above, maybe that could help.

title bar buttons are not working even after reinstalling the application.

so here we go, just installed powertoys v0.15 rebooted the machine and opened windows terminal

it also affect pt settings:

here is the original video clips:
bug-videos.zip

@LuanVSO does this happen without PowerToys running?

@crutkas no, when i stop pt it goes back to normal behavior

Can you create a step by step and where you are clicking?

1. launch terminal (it is pinned on my task bar so i press win +2)
2. right-click on minimize button (doesn't work)
3. right-click on split-button(doesn't work)
4. hover mouse over edges of the window to show how the pointer behave (resizing the window does work, but it would stop the recording so i didn't)

for the life of me, i can't repo this. can you email me and maybe lets do a teams sync where we can screen share? [email protected]

ok, i mean i can't repo this every time neither, it is very finicky

if it follows the pattern i outlined above, that is outside powertoys and i can repo this without PT running.

What i'm doing to recreate

1. launch terminal
2. Left-Click on title bar
3. Hold shift
4. Drag mouse downward and into the console screen itself
5. Release mouse

@crutkas i think i found out whats happening.

1. pin win terminal to taskbar
2. hold win key down
3. just before the shortcut guide comes up press the # corresponding to win term and release both keys quickly
4. try interacting with the controls on win term

also, shortcut guide doesn't comes up anymore after doing these steps

For me, the title bar is working, the issue I am having is with Drop Down for profiles and setting. While using the VS2019 debug, it causes an exception.
I can open a new terminal in debug mode with "ctrl+shift+ 2,3,4", but if a select the drop-down button.

Unfortunately, _that_ is a platform bug (which seems to have been fixed in 19041+). Sorry :smile:

I've got the same on my machine but it gets even trickier.
It only happens on my primary screen. When I move WT window to the other screen everything goes back to normal. Same symptoms, window not receiving mouse events, even the cursor freezes over WT window. Max/Min/Close does not work, have to move the window to the other screen for it to work.
I am PT user as well and apparently turning it off helps immediately.
However @crutkas repro steps work as well without PT running.

@DHowett-MSFT is this supposed to be funny? That's still on Insiders only... Well, luckily WT still can't compete with my current setup so no worries..
I'll just wait that through and get back in half a year or so.

@DHowett-MSFT is this supposed to be funny?

Just so I'm clear: you think that this bug that _nobody on my team can reproduce, and we're in discussion with the input team about_ is a joke we're playing on you? That's cool.

I had the same issues at https://github.com/microsoft/terminal/issues/5724 and I don't have any issue after updating PowerToys to version 0.17.0

Those of you who were seeing this issue with PowerToys, can you check whether it's still a problem as of PowerToys v0.17.0? Thanks.

No, I didn't have to disable it to get it work. I closed PowerToys, updated, and opened it again. It is important to mention that I used Scoop to install PowerToys.

it is not happening anymore for me too

Those of you who were seeing this issue with PowerToys, can you check whether it's still a problem as of PowerToys v0.17.0? Thanks.

Came here the first time I spotted this - yeah powertoys 0.17.0 has the same issue (the only version I ever installed in fact). It just happened to me. In fact when the issue is exhibiting itself, the mouse doesn't even work within powertoys either. Nor do I even really use powertoys tbh I was just trying it out. When I kill powertoys the issue goes away. When I restart powertoys the issue is still not present, so assuming that this is related to some sort of event combination causing deadlock that locks up both apps :(. I'll try and pay closer attention to any preceding events next time it happens but I pity you trying to troubleshoot this one.

Just happened to me with PowerToys 0.18.0, restarting PowerToys seems to have fixed the issue.

found out a sure way to repro this on powertoys 0.18.1:
here is the step record file i did (now it is in the right language 😅 ):
powertoys unresponsive window bug.zip
it has to be the first time that shortcut guide is triggered, otherwise it wont repro

I managed to reproduce this bug, as reported in PowerToys #4287. If Fancy Zones is turned off, PowerToys restarted, and Fancy Zones turned on, it works as expected.

I disagree this is PT directly, i can recreate this bug without powertoys running. the terminal window rendering freezes. FancyZones amplifies the issue due to the hotkey

What i'm doing to recreate

1. launch terminal
2. Left-Click on title bar
3. Hold shift
4. Drag mouse downward and into the console screen itself
5. Release mouse
6. type

you'll see the cursor stop and all input stop coming in.

does it behave like this when shift is released?

Does this drop after you let go?

k,
so there are 2 bugs here:

1. is that shift dragging wt causes it to hang
2. is this

found out a sure way to repro this on powertoys 0.18.1:
here is the step record file i did (now it is in the right language 😅 ):
powertoys unresponsive window bug.zip
it has to be the first time that shortcut guide is triggered, otherwise it wont repro

here is a gif showing the process:

when i released the win key i could no longer interact with the buttons on pt settings

I managed to repro the bug in a debug buid of pt, and when i paused the execution it droped me in this file

this seen to be happening when the d2doverlaywindow is being created, as the bug only happens if it is the first time it is being displayed

@LuanVSO
the bug you found when long pressing the Win key while remapping a key is unrelated to the Terminal bug when shift dragging it.

This happened to me with Terminal version 1.0.1811.0

Looked like a conflict with PowerShell:
I had version 7 installed, and also I had .Net which also installed PowerShell but version 6. Uninstalling the PowerShell from .Net seemed to fix the issue for me.

@DHowett I get the same issue on Powertoys 0.18, not able to use the mouse to click on power toys or the windows terminal. Uninstalling powertoys solves the problem.

Can someone confirm that quitting PowerToys is not enough to prevent this bug and it requires to uninstall it?

@DHowett-MSFT
this is a very interesting (and weird) discovery:
https://github.com/microsoft/PowerToys/issues/5944
Terminal, for some unknown reason, is using a window class defined in PowerToys.
The steps recorder shows the UI element that is "stealing" the input, is part of Terminal, not PowerToys.exe.
Not clear what is going on here, is Terminal actively creating this UI element or is PowerToys that is somehow injecting this into Terminal?

@enricogior Good catch. The Terminal certainly isn't creating that window class - the only window we create manually is our CASCADIA_HOSTING_WINDOW_CLASS (see IslandWindow.cpp#L18-L68).

Technically, we're also creating a XAML Island - maybe that's somehow interacting with the shortcut guide somehow?

When this occurred for me, I was simply able to restore functionality by disabling the "Shortcut Guide" powertoy. Uninstalling would _also_ work, but might be a tad bit excessive 😄

I'm just realizing that #6120 also has a ton more info about this issue and a bunch of other repros in it.

@zadjii-msft
the Shortcut Guide is a pure C++ app, the fact that the window class defined in Shortcut Guide ends up in Terminal is quite surprising.

@enricogior terminal is a native C++ app too. The language in use has no bearing on the window classes that are possible.

@DHowett
I meant pure Win32, no XAML, the only thing I've found so far that can be a potential entry point for the problem is described in
https://github.com/microsoft/PowerToys/issues/5944#issuecomment-674981994
I suggested to build a debug version of Terminal to monitor that class name to verify if the Steps recorder is correctly identifying the UI element as child of the Terminal process, it would confirm that there is an injection of the class object from outside.

This has now happened to me as well, but actually a hybrid of this and https://github.com/microsoft/terminal/issues/4448 where I can't type nor can I click on title bar buttons or scroll or use any UI element (I can resize the window, though). This has happened more than once.

• I am using PowerToys v0.20.1
• I am not using the shortcut guide
• resizing and snapping the windows (win+arrow) works
• clicking into the window (titlebar, tab bar, min/max/exit) doesn't work
• typing into the window has no effect
• the shell is powershell (and then running wsl inside that), and the process tree is still alive
• I am running 150% DPI scaling, but I only have 1 monitor plugged in
• I started the app yesterday, and the computer has slept/woken since then. I only noticed the problem after waking the computer
• I started a second instance of the terminal app, and it works fine

@aharpervc

I am not using the shortcut guide

Is Shortcut Guide turned off in the PowerToys settings or simply you are not invoking it?

It's turned off:

@aharpervc
thank you.

That seems to exclude the possibility that the bug is caused directly by Shortcut Guide, since it's not running and therefore it can't be what is injecting the PToyD2DPopup class in the Terminal process.

@aharpervc what graphic chipset are you running? NVidia?

@aharpervc what graphic chipset are you running? NVidia?

AMD Radeon Pro 560

I was also experiencing this issue (Cannot interact with Power Shell window bar other than drag it around). Restarting windows & killing the 'Windows Terminal' app in the task manager do not fix it for me.

Power toys version 0.19.1
Windows 10 Pro 19042.541

I just opened Power Toys to check if my shortcut guide was enabled as suggested above but I couldn't interact with that UI either. I then killed the 'Powertoys runner' process using task manager and it fixed both issues for now at least.

Good thing I found this thread on Google!
After updating to Windows 10 feature release 2004 last week, I could not click anywhere on the titlebar of the Windows Terminal App (neither tab controls or minimize/maximize/close).
Was not possible to select text in the terminal window either.
Problem disappeared immediately when closing Power Toys in the tray 👍

In my case, this happens to both Windows Terminal (Version: 1.4.3243.0) and Windows Terminal Preview (Version: 1.5.3242.0) whether or not PowerToys (Version: 0.25.0) is running. My Windows 10 version is 1909 and OS Build is 18363.1198.

This is probably useless information, but using WindowSpy (Autohotkey inspection component), I've noticed there is a difference between the class name/instance number (ClassNN in WindowSpy) of the controls involved.

When I _can_ interact with the mouse hovering over the New Tab button or any of the minimize/maximize etc buttons:

ClassNN:  Windows.UI.Composition.DesktopWindowContentBridge1
Text:     DesktopWindowXamlSource

When I _can not_ interact with the mouse on these controls this changes to:

ClassNN: Windows.UI.Core.CoreWindow1
Text:        DesktopWindowXamlSource