After minimizing, unable to restore window with Alt-Tab

[vertigo220]

Windows Terminal version

1.14.1962.0

Windows build number

Version 21H2 (OS Build 19044.1826)

Other Software

No response

Steps to reproduce

Open and minimize terminal
Press Alt+Tab to switch back to it
Previous app loses focus, but Terminal doesn't show and remains minimized

NB: When this happened, I tested it multiple times, and it happened every time. I then restored the window and Alt+Tab worked normally, then minimized it and it didn't. However, now it's working fine, so I'm not sure if it was some weird Windows issue (W10 continues, to this day, to be extremely broken WRT focus issues, constantly leaving windows I click on behind other windows and requiring me to click on the foreground, unfocused window then click back in the other one to force it to come to the front). Still, I'm reporting just in case it is actually an issue, and maybe somebody else can reproduce it or will have it happen to them to confirm.

Expected Behavior

No response

Actual Behavior

See above

[babico]

I have same issue I tried change preview to stable version but it didn't change anything, still happening this bug.

[zadjii-msft]

Does this only happen when running elevated (as Administrator)? this looks similar to #13592 which was just filed. I can't repro this here on Windows 11, but maybe the focus/foreground work attached to #2988 regressed this in Windows 10 😨

[babico]

Does this only happen when running elevated (as Administrator)? this looks similar to #13592 which was just filed. I can't repro this here on Windows 11, but maybe the focus/foreground work attached to #2988 regressed this in Windows 10 😨

Yes, it happen on administrator mod I didn't even notice the administrator mod.

[vertigo220]

Sorry, I forgot to mention this in my OP, but it was NOT running as admin at the time. And, if it matters, I had about four or five tabs open, with a mix of PS and cmd.

[zadjii-msft]

Alright, I'm deduping here, this will be the master tracking thread.

• Doesn't seem limited to Windows 10 (at least, I can repro this on win11 in an elevated window sometimes)
• Only occurs when minimizing to the taskbar, using the taskbar icon itself.
• Doesn't seem limited to elevated windows (but seems more frequent)
• If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

There's also MSFT:40530963 tracking internally.

[vertigo220]

• Only occurs when minimizing to the taskbar, using the taskbar icon itself.

Ah, and there it is. Kinda surprised I didn't think to try this, but yeah, if I minimize this way, it happens every time, with a non-admin window. Doesn't get stuck though, just have to click the taskbar button again.

[lhecker]

@zadjii-msft I narrowed it down to 6b936d9. Commenting out this line fixes the issue:

terminal/src/cascadia/TerminalControl/ControlCore.cpp

Line 1929 in feabe41

conpty.ShowHide(showOrHide);

I tried various ways to debug this further and fix the issue, but failed at it so far. 😥

[zadjii]

I wonder if it's because that results in a xproc call (sending a message to OpenConsole.exe via a pipe) on the main thread. I wonder if user32 doesn't like us doing that... A resume_background right before that would be an interesting experiment

[philipphutterer]

Same problem here, windows 10, elevated terminal.
Though this hint was pretty helpful since I closed many windows with multiple tabs and sessions open so far. Thanks for that.

If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

[zadjii-msft]

Notes (ongoing)

• I was able to get an unelevated dev build of the Terminal into this state, on Windows 11.
• In that state, we only get a few messages when alt-tabbing to the window:
  • 0x7f
  • WM_WINDOWPOSCHANGING
    • the flags are: 0x13 = SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOMOVE
    • hwndInsertAfter is not a special value.
  • WM_WINDOWPOSCHANGED
  • and that's it. There's nothing else, no ShowWindow or anything...
• We don't even get into ControlCore::_focusChanged even remotely. Checks out, the window never gets shown so no duh it's not getting focused.
• The current window styles are... 34CF0000 -> WS_VISIBLE | WS_MINIMIZE is set...
• The ConPty HWND seems to be owned correctly, and WS_VISIBLE | WS_MINIMIZE are both set
• Below is two tabs worth of messages on attempted alt-tabbing:

  MessageHandler: 0x00000046 WM_WINDOWPOSCHANGING
  InteractivityFactory::PseudoWindowProc 0x00000047 WM_WINDOWPOSCHANGED
  InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT
  InteractivityFactory::PseudoWindowProc 0x00000047 WM_WINDOWPOSCHANGED
  InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT
  MessageHandler: 0x00000047 WM_WINDOWPOSCHANGED
  InteractivityFactory::PseudoWindowProc 0x0000001c WM_ACTIVATEAPP
  InteractivityFactory::PseudoWindowProc 0x00000086 WM_NCACTIVATE
  InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT
  InteractivityFactory::PseudoWindowProc 0x0000000d WM_GETTEXT
  InteractivityFactory::PseudoWindowProc 0x00000006 WM_ACTIVATE
  InteractivityFactory::PseudoWindowProc 0x00000281 WM_IME_SETCONTEXT
  InteractivityFactory::PseudoWindowProc 0x00000282 WM_IME_NOTIFY
  InteractivityFactory::PseudoWindowProc 0x00000007 WM_SETFOCUS
  MessageHandler: 0x0000001e WM_TIMECHANGE
  InteractivityFactory::PseudoWindowProc 0x0000001e WM_TIMECHANGE
  InteractivityFactory::PseudoWindowProc 0x0000001e WM_TIMECHANGE
  

• Activating the child conhost seems... weird? But maybe harmless
• This repros way more frequently in a win10 VM. There, the first time I try to minimize by clicking on the taskbar, it doesn't do anything. Like, the window just stays open. If I click the taskbar again, it does minimize. THAT is when the window gets stuck. Friggen weird.
• Debugging with Evan:
  • When we first click the taskbar icon, the kernel tries to SwitchToWindow to the main terminal window. That's by itself not that weird. Maybe the OS doesn't think the Terminal window is active & FG. Not terribly uncommon, but still weird.
  • The next click: The main terminal window minimizes, via xxxminmaximizeex.
  • The conpty window minimizes as a result (unclear how exactly. Presumably, due to conpty minimizing itself via ConhostInternalGetSet::ShowWindow's call to ::ShowWindowAsync(hwnd, showOrHide ? SW_SHOWNOACTIVATE : SW_MINIMIZE)
  • At this point, both windows are minimized.
  • You alt-tab to the window.
  • xxxSwitchToThisWindow gets called ON THE CONPTY HWND. Why that one?
  • Why doesn't that end up restoring the terminal HWND? If anything, it restores the conpty hwnd, so it should cause the Terminal to get SC_RESTORE'd
• Even outside of the repro case:
  • We hit IslandWindow::ShowWindowChanged(false) every time we minimize with the taskbar. What? why. That doesn't make sense, right? Like
  • we DONT get a IslandWindow::ShowWindowChanged(true) on restore. wat
• In the repro case:
  • We don't get a TerminalPage::_ShowWindowChanged on the attempted restore. I suspect we never get it out of conpty.
  • Nope we don't get bp Microsoft_Terminal_control!winrt::Microsoft::Terminal::Control::implementation::ControlCore::_terminalShowWindowChanged.
  • Nor do we hit a bp Microsoft_Terminal_control!Microsoft::Console::VirtualTerminal::AdaptDispatch::WindowManipulation. So it's not even getting out of the conpty.

[zadjii-msft]

In the 10 VM, the taskbar icon is not immediately highlighted when launching the Terminal. As if it doesn't know that the terminal is in the FG. That would explain the initial SwitchToWindow

But then after the "restore", the terminal is indicated as being active. Hmm.

[zadjii-msft]

#13158

    // BODGY
    //
    // GH#13158 - At least temporarily, only allow the PTY to HIDE the terminal
    // window. There seem to be many issues with this so far, and the quickest
    // route to mitigate them seems to be limiting the interaction here to
    // allowing ConPTY to minimize the terminal only. This will still allow
    // applications to hide the Terminal via GetConsoleWindow(), but should
    // broadly prevent any other impact of this feature.
    //
    // Should we need to restore this functionality in the future, we should
    // only do so with great caution.

Oh hey look, that came back to bite 😠

[satyapramodh]

@zadjii-msft If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

• this doesnt work for me on windows 11. my cmd prompt is elevated. this happens to me every day more than once everyday of the week.
  I am on windows 11 21H2, Win Terminal v1.14.1963.0

[vertigo220]

@satyapramodh Your screenshot only shows you hovering over the thumbnail. Did you actually right-click on the thumbnail and select restore from the menu that pops up? Granted, I'm on W10, but that does work for me and others, and it looks like zadjii is on Win11, like you, so it seems it should work for you as well.

[aaronedev]

Ok - restoring the window does actually work, but is quite annoying. Shouldn't have updated the terminal at all, the old version was working quite fine. 😅

[rpodric]

Just to chime in that it happens on Win11 22H2, too

The "right-click on the thumbnail and select restore" trick, which may be the only thing I hadn't tried, does get it back, but it's almost impossible to remember not to minimize it from the taskbar, so it keeps happening.

[pimpace]

@zadjii-msft said:
If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

No need to wait for preview of the window, for this "hover thing", simply shift-rightclick on the Terminal taskbar button and
click restore. A little bit simpler. :)

[ghost]

🎉This issue was addressed in #13624, which has now been successfully released as Windows Terminal v1.14.228.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #13624, which has now been successfully released as Windows Terminal Preview v1.15.228.:tada:

Handy links:

• Release Notes
• Store Download

[vertigo220]

Those "handy" links are 404. They're missing the ".0" on the end.

[pheu]

Those "handy" links are 404. They're missing the ".0" on the end.

Yup, both links are very "handy". One misses .0 and another points to the store where they still keep older buggy version (200). 😁

[rpodric]

The Store just got 1.14.2282.0.

[aaronedev]

The Store just got 1.14.2282.0.

thanks for letting us know

[badjuice]

@zadjii-msft said: If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way

No need to wait for preview of the window, for this "hover thing", simply shift-rightclick on the Terminal taskbar button and click restore. A little bit simpler. :)

This is not an option on Windows 10 :(

[Bartizan]

@zadjii-msft said: If you're stuck in this state, you should be able to hover the icon in the taskbar till you get a preview of the window, and then you can right click -> "Restore" the window that way
No need to wait for preview of the window, for this "hover thing", simply shift-rightclick on the Terminal taskbar button and click restore. A little bit simpler. :)

This is not an option on Windows 10 :(

it works for Win10, also see the same workaround here #13592 (comment)
But now it seems to work as it should at least for me.