Other applications open behind the Terminal window - (ConPTY window handle z-order shenanigans with GetConsoleWindow)

[amithegde]

Description of the new feature/enhancement

When I open File explorer from terminal using command such as start . control should shift to explorer window but it remains in terminal.

Proposed technical implementation details (optional)

when file explorer starts control should shift to explorer and any further keyboard interaction should be targeted to explorer window.
You can verify how ConEmu or cmd works to validate this.

[amithegde]

I noticed it does shift control some times. So I guess it's a bug? Some times control doesn't shift and some times it shifts?

[zadjii-msft]

This might not be possible. This repros for any conpty session.

I (believe) that traditionally, start uses GetConsoleWindow to get the HWND of the console, to place explorer (or any application really) in the z-order above the conhost.exe window.

For something running in conpty however, the console doesn't actually have a window. The Terminal does, but the console doesn't. So there's no way for start to place something above the console window, since there is no console window.

[fpqc]

I can't imagine it would be hard for a motivated person to write a small Windows program that launches a program and then sets it at the top of the Z-order without comparing against the current window.

[amithegde]

This might not be possible. This repros for any conpty session.

I (believe) that traditionally, start uses GetConsoleWindow to get the HWND of the console, to place explorer (or any application really) in the z-order above the conhost.exe window.

For something running in conpty however, the console doesn't actually have a window. The Terminal does, but the console doesn't. So there's no way for start to place something above the console window, since there is no console window.

I will be demotivated to use Terminal in that case since it doesn't behave consistently with existing tools like cmd😒

[dracan]

Not sure if this information is useful or not, but I had created a similar issue #3636 which got closed as a duplicate of this current issue. In my case, it was git difftool that was causing winmerge to not appear in the foreground. I've just discovered that whilst it happens when I do a normal git difftool, which triggers a Launch 'winmerge' [Y/n]? prompt - if instead I do git difftool -y, which suppresses that prompt - it works as expected.

[dracan]

Although, if more than one file has differences - the first launch of winmerge is in the foreground (when specifying the -y mentioned in my previous post), however any subsequent ones have the issue where the winmerge window is right at the back of all other windows.

I've also just noticed that the same issue happens from the vscode terminal. It doesn't happen when using the native Powershell terminal window though.

[zadjii-msft]

I have nowhere else for good notes, so sorry for the kinda random ping here folks:

b257581 status

As of b257581, this is starting to work a little better

Turns out there's piles of edge cases. Seemingly different things zorder in different ways, which is complicating this. Duping everything to this thread may not have been the most wise ;___;

---

Changed the reparenting to the root terminal HWND instead of the xaml island, and we get:

so GetAncestor(GetConsoleWindow(), GA_ROOT) can work the same for WT and conhost

See also:

• [Bug] If a window handle is not passed to WAM, the account picker can be parented to foreign windows AzureAD/microsoft-authentication-library-for-dotnet#2469
• WAM account picker should be parented to the console window git-ecosystem/git-credential-manager#469 (comment)

Scenarios:

• ExchangeOnlineMangement , Azure Az Powershell login popup opens in background. Connect-AzAccount
  • ExchangeOnlineMangement module authentication window opening under Windows PowerShell Terminal #11776
  • Windows PowerShell opens ADAL forms page in background #6084
  • authentication prompt show in the background #11464
  • The Connect-AzAccount looks to be the same as well.
    • PowerShell cannot execute Connect-AzAccount command #6053
    • Azure Az Powershell login popup opens in background #8679
  • Import-Module -Name ExchangeOnlineManagement ; Connect-ExchangeOnline
    • This seemingly opens an Edge window to do the auth. Hmm.
    • PowerShell 5 opens a dialog of some sort
      • ❌ Does not work in 5d96691 + always use WS_OVERLAPPED
      • In both preview and dev, it does open on the correct monitor, but beneath the Terminal. Presumably tries to parent the window to an invisible or a child window and that doesn't work.
      • In conhost this dialog isn't a child, it's just before it in the ordering. I wonder if it's just trying to insert it BEFORE the GetConsoleWindow?
      • Mail out.
      • ⁉️ SOMETIMES JUST WORKS
    • ✅ PowerShell 7 opens the prompt in Edge / default browser.
• get-credential does not work with powershell 5, works with powershell 7,
  • get-credential does not work with powershell 5, works with powershell 7 #11847
  • ✅ This one is seemingly already fixed in main. I don't think we did anything here, but I certainly can't repro this anymore. Get-credential consistently acts as a proper dialog in the Terminal, and you can't focus the Terminal without focusing the dialog
• Print Dialog via :hardcopy in vim.exe
  • Print Dialog Shown Off Screen #10693
  • Seems to work well enough with 5d96691 + always use WS_OVERLAPPED. In that version, the dialog always appears "on" the terminal hwnd, but doesn't block input like a dialog usually does (and does for conhost). ~This might be the "it sometimes works just fine" case, where things appear at the top of the z ~
  • ✅ Actually, yea this is MUCH better than the preview version, where it appears centered on 0,0 😨
• Powershell show-command Get-ChildItem, Out-GridView, Get-Help -ShowWindow
  • Show-Command popup behind wt window instead of getting focus. #10345
  • Graphical Tools cmdlets in PowerShell 7 Preview 6 open windows behind the Terminal #3665
  • Out-Gridview window launches behind instead of in foreground #9888
  • Dialog Focus #10161
    • "Powershell script that opens a Windows Dialog" - this isn't very clear, but sounds the same
  • ❌ Not fixed as of 5d96691
  • See: https://github.com/PowerShell/PowerShell/blob/7dc4587014bfa22919c933607bf564f0ba53db2e/src/Microsoft.PowerShell.Commands.Utility/commands/utility/ShowCommand/ShowCommand.cs#L226, https://github.com/PowerShell/PowerShell/tree/7dc4587014bfa22919c933607bf564f0ba53db2e/src/Microsoft.Management.UI.Internal
  • https://github.com/PowerShell/PowerShell/blob/7dc4587014bfa22919c933607bf564f0ba53db2e/src/Microsoft.Management.UI.Internal/commandHelpers/ShowCommandHelper.cs#L961 seems to be where the window is created.
    • SetupWindow - not helpful
    • CommonHelper.SetStartingPositionAndSize - not helpful
    • Window.Activate is defined here: https://github.dev/dotnet/wpf/blob/91fb2e1bc4bf6520d1039056d3dcde8236ce7b58/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Window.cs#L513. It's just doing SetForegroundWindow. Ruh roh.
• missing dll popup from NtRaiseHardError
  • Windows terminal does not show missing dll popup #9788
• cmd.exe's start (which is what this thread was originally about)
  • START "ms-settings:" and focus? #7415 - START "ms-settings:".
    • ❌ Not fixed as of 5d96691
    • Might only apply to URI activation though. Needs more investigation.
• The WT window always appears behind the active Explorer window.
  • This actually isn't a dupe at all.
  • The WT window always appears behind the active Explorer window. #7036
• WinForms dialog not popping up on top of Windows Terminal
  • WinForms dialog not popping up on top of Windows Terminal #6633
• Maybe related: No keyboard input while the Get-Credential dialog is open #11185

[zadjii-msft]

Misc notes:

    gci.ProcessHandleList.ModifyConsoleProcessFocus(WI_IsFlagSet(gci.Flags, CONSOLE_HAS_FOCUS));

    ...

    // ModifyConsoleProcessFocus calls _ModifyProcessForegroundRights

    ...

void ConsoleProcessList::_ModifyProcessForegroundRights(const HANDLE hProcess, const bool fForeground) const
{
    LOG_IF_NTSTATUS_FAILED(ServiceLocator::LocateConsoleControl()->SetForeground(hProcess, fForeground));
}

FocusIn/FocusOut

FocusIn/FocusOut can be combined with any of the mouse events since it
uses a different protocol. When set, it causes xterm to send CSI I
when the terminal gains focus, and CSI O when it loses focus.

The easiest prototype may just be always passing true here in conpty mode.

---

graph TD
    id1[ \u2705Allow windows created by console <br> apps to appear above the Terminal #12799] --> id3[ \u2705Check if FG window is owner #12899]
    id2[ \u2705 Enable the Terminal to tell ConPTY <br> who the owner is #12526] --> id3
    id3 --> id4[ \u2705FocusEvents in conhost, terminal, #12900]  --> id6
    id5[ \u2705 Propagate show/hide window calls against <br> the ConPTY pseudo window to the Terminal #12515] --> id6{{Terminal v1.14}}
    click id1 "http://www.github.com/microsoft/terminal/issues/12799"
    click id2 "http://www.github.com/microsoft/terminal/issues/12526"
    click id3 "http://www.github.com/microsoft/terminal/issues/12899"
    click id4 "http://www.github.com/microsoft/terminal/issues/12900"
    click id5 "http://www.github.com/microsoft/terminal/issues/12515"

Loading

April 7 status update: flowchart above has dependency tree. Gonna stack the PRs in the bubbles on top of #12799, once #12526 merges. We won't have time to review that this week though.

April 27th update: all the above PRs have signoffs &/|| are merged. Should all be available in 1.14.

[zadjii-msft]

Alrighty. With #12515, #12526, #12799, #12899, #12900 all merged, I think this one's done. Everything I found linked to this thread seems to work in main. At this point, any new issues we discover in 1.14+ will be something else entirely, so we should give them new threads.

Thanks for the patience here folks!

[zaaj]

Terminal version 1.19 on Windows 11 here almost half way through 2024 and this is still a problem - Microsoft Graph login-prompt windows usually show up behind the Terminal window that launches them, I also have intermittent issues with Get-Credential in windows powershell 5.1 (pwsh 7 not having all the functionality I use on a day-to-day basis, I'm still feeling stuck on 5 - plus, writing my scripts for 5 makes them more sharable with my less-powershell-savvy colleagues, and is easier to run them on servers where we don't want to install any software not needed, including Pwsh 7).

From a technical programming standpoint, I can understand a ConPTY process not having a console window, but it is obviously being show IN a window, which DOES have a window handle. With 5 PRs all trying to attempt to resolve this, it would appear to be a hard-to-fully-resolve issue. I appreciate that work had been done towards resolving this issue, but it does not appear to be resolved yet. Please keep working on this issue.