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]

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.