window of a windows terminal is appending to the end of windows stack

[beqabeqa473]

trafficstars

Windows Terminal version

1.17.11461.0

Windows build number

Version 22H2 (OS Build 19045.3086)

Other Software

No response

Steps to reproduce

Open windows terminal; Press Alt+Tab to go to another window; Press Alt+Tab again.

Expected Behavior

I should go to Windows terminal window again by pressing Alt+Tab

Actual Behavior

I am getting second window in the windows stack instead of windows terminal and windows terminal is beeing appended to the end of stack and i need to press alt+shift+tab to find a terminal window

[carlos-zamora]

Hi @beqabeqa473. We've got a few questions for you:

• Do you happen to know if this happens with other versions of terminal (1.16 or 1.18)?
• Or other apps on your machine?
• Maybe only when NVDA is running?

[beqabeqa473]

Hello.

It happens with 1.16 as well as with 1.18 i cannot tell if this only happens when nvda is running because i cannot test this without nvda, but i think window reorderring should not be nvda fault.

[jry2]

I have the same problem on my desktop and laptop. Both with Windows 11. I tried closing the other running applications, but I couldn't locate the problem.

I have been observing the problem for several months, on older versions of Windows 11 and Windows Terminal.

[jry2]

This problem is also mentioned in this post: https://superuser.com/questions/1777841/windows-terminal-isnt-added-to-tab-history-when-started-via-the-run-dialog

I can confirm that the WT taskbar icon is indeed not rendered as active (longer horizontal line below the icon), although the window responds normally to keystrokes.

Something changed during the tests and now I am unable to reproduce the problem. I was able to reproduce it when running cmd.exe.

[jry2]

[jry2]

Reproduction sample: https://github.com/jry2/WTTabProblem

See WTProblem function: https://github.com/jry2/WTTabProblem/blob/ec0d81601268110b25748bcbc778e4f65ea64bb8/WTProblem.cpp#L114C6-L114C15

[petrsol]

I have the same problem on my win11 22H2 22621.2134. More accurately, it sometimes works well and sometimes goes to back of windows stack. Unfortunatelly I have no idea how to reproduce it for sure.

[WilliamK7]

I have the same problem on my win11 22H2 22621.2134. More accurately, it sometimes works well and sometimes goes to back of windows stack. Unfortunatelly I have no idea how to reproduce it for sure.

According to this post, it seems that you need to use Win+R to call Terminal to reproduce

[jry2]

I'm not sure if this is the same problem. If I run cmd from the task manager, the window appears in the background, but cursor is blinking. It doesn't accept keys (until after activation). If I run wt instead, everything works correctly.

[WilliamK7]

So the temporary solution is to run wt instead of cmd/powershell, right?😀

[rzvxa]

So the temporary solution is to run wt instead of cmd/powershell, right?😀

It is funny, I have version 1.19.2682.0 and it only works when I launch using cmd/powershell, launching via the Windows terminal starts the process in the background.

[rubenwe]

Same issue here!

[rzvxa]

Same issue here!

Can you try pressing Windows + D and bring your windows up manually again and test it once more? If that didn't work please also try to restart your machine.

As of today, I observed weird behavior from this bug, I usually put my machine to sleep instead of shutting it down, Last night I turned off my PC after a long time, and today it seemed like the problem had been solved just for it to happen again after a while. When it started to show this issue again I used Windows + D to get back to the desktop and then brought my browser and other windows up manually from the taskbar and the issue was gone once again.

@lhecker @zadjii-msft if you guys have an idea of where the problem is originating from please give some insight about it, Right now I'm transitioning between jobs and I have some extra free time so maybe I can help with solving it. If there is already a fix for it in the work let me know so I don't spend any time on it, My day job is game engine development so I think there is a lot of overlap between rendering a game and rendering a terminal. But even with that in mind, it is going to take a while for me to familiarize myself with the codebase.

[lhecker]

We haven't started working on this yet and I personally wouldn't know why this happens either - this seems like something that would just need random experimenting.

That said, this bug doesn't happen on my machine in the first place... 😐 If the issue happens mostly (or only) when using Win+R then the cause would be something we call "handoff". I'm not the most familiar with that code or our windowing, but things that worry me generally speaking are these two places:

• https://github.com/microsoft/terminal/blob/86fb9b44787accd09c5943a506e27eb4c8e573c0/src/cascadia/WindowsTerminal/IslandWindow.cpp#L979-L993 Since https://github.com/microsoft/terminal/commit/6b936d9a74a5d677387f3edc9a68e6b33d566606 we propage the visibility of Windows Terminal down to ConPTY so that console applications know whether they're currently visible or not. Also, it allows them to make themselves visible. The current implementation however is imperfect, because Windows Terminal starts in a visible state, while ConPTY starts in an invisible state. So when we send the initial ShowHide message "hey ConPTY you're visible", then it'll trigger a visiblity change in ConPTY. This is (currently) indistinguishable of a programmatic change, and so it'll cause it to emit "hey I just changed visibility" message back to Windows Terminal which will end up calling the above function. Due to the IsIconic check this should then not do anything normally, but I'm a bit worried if this code can be in a race condition with the next bullet point's function. Because if this one is faster than the next one, is it possible that we'll do a SC_RESTORE before we show the window, causing this issue?
• https://github.com/microsoft/terminal/blob/86fb9b44787accd09c5943a506e27eb4c8e573c0/src/cascadia/WindowsTerminal/AppHost.cpp#L1407-L1467 This function is responsible for showing the window initially. This code worries me because it does a manual SetForegroundWindow, which I haven't seen in other Win32 applications before. It's also only called once WinUI did its initial layout pass (= quadrillions of CPU cycles, because why), which worries me in combination with the previous bullet point, because of the interaction with IsIconic. (Just to be clear, I'm not sure if the window is considered iconic or not at this point - I'm just guessing). Also, Windows Terminal may launch with multiple windows concurrently and I'm not sure how SetForegroundWindow performs in that situation.

[oldium]

We haven't started working on this yet and I personally wouldn't know why this happens either - this seems like something that would just need random experimenting.

That said, this bug doesn't happen on my machine in the first place... 😐 If the issue happens mostly (or only) when using Win+R then the cause would be something we call "handoff". I'm not the most familiar with that code or our windowing, but things that worry me generally speaking are these two places:

• https://github.com/microsoft/terminal/blob/86fb9b44787accd09c5943a506e27eb4c8e573c0/src/cascadia/WindowsTerminal/IslandWindow.cpp#L979-L993

  Since 6b936d9 we propage the visibility of Windows Terminal down to ConPTY so that console applications know whether they're currently visible or not. Also, it allows them to make themselves visible. The current implementation however is imperfect, because Windows Terminal starts in a visible state, while ConPTY starts in an invisible state. So when we send the initial ShowHide message "hey ConPTY you're visible", then it'll trigger a visiblity change in ConPTY. This is (currently) indistinguishable of a programmatic change, and so it'll cause it to emit "hey I just changed visibility" message back to Windows Terminal which will end up calling the above function. Due to the IsIconic check this should then not do anything normally, but I'm a bit worried if this code can be in a race condition with the next bullet point's function. Because if this one is faster than the next one, is it possible that we'll do a SC_RESTORE before we show the window, causing this issue?

• https://github.com/microsoft/terminal/blob/86fb9b44787accd09c5943a506e27eb4c8e573c0/src/cascadia/WindowsTerminal/AppHost.cpp#L1407-L1467

  This function is responsible for showing the window initially. This code worries me because it does a manual SetForegroundWindow, which I haven't seen in other Win32 applications before. It's also only called once WinUI did its initial layout pass (= quadrillions of CPU cycles, because why), which worries me in combination with the previous bullet point, because of the interaction with IsIconic. (Just to be clear, I'm not sure if the window is considered iconic or not at this point - I'm just guessing). Also, Windows Terminal may launch with multiple windows concurrently and I'm not sure how SetForegroundWindow performs in that situation.

If you are not able to repro, I recommend repeating the steps from my bug report. On my PC it happens once you reorder the Windows Terminal windows stack (click on the first one). Otherwise it looks like it works.

1. Open File Explorer, place it on the screen so that new Windows Terminal window must open over it.
2. On address bar of File Explorer, write wt and press Enter.
3. New Windows Terminal window opens in front of other windows and gets focus.
4. Switch back to File Explorer's address bar, write wt and press Enter.
5. New Windows Terminal window opens in front of other windows and gets focus.
6. Click on the first Windows Terminal window's title bar (move the second Windows Terminal window first - if necessary).
7. Switch back to File Explorer's address bar, write wt and press Enter.
8. Observe that the Windows Terminal window is opened in background (not over File Explorer, but below it), has blinking cursor like it has focus, but it does not have focus.

[JollyRgrs]

not sure if I have the same issue or completely different. I normally launch my first instance of terminal via a taskbar pin to a specific shell (launches ssh.exe directly into a specific box), that has no problem popping on top of things already on the screen. If I use the start menu and open the Windows "Terminal" app, it pops under and is in a random place. At the moment, I have a list of 23 items in my alt+tab view and it gets place 19 (my initial terminal window is in spot 3). If I close all terminal windows and open a terminal via start menu, the first instance works and the second goes in the background, always seemingly in the same spot (I have 5 chrome windows open at the end of my alt+tab (not all my chrome windows, but just some) and it always places just prior to them at the 6th from last spot.

If I go to start and type "wt" and launch it that way, it will always pop up on top . It is just the "Terminal" app option from the start menu (and only instances after the first terminal).

This is Terminal version 1.20.11381.0 on Windows 11 23H2 (OS Build 22631.3737)

[rzvxa]

@JollyRgrs I feel that is related! I can confirm it is still an issue but I couldn't find the source with the limited time I've put into it, I guess I'm just not familiar with the code base. In addition to that I've only worked with Windows windowing API in game development so it is safe to say that I've used it minimally mostly doing fullscreen.

I would like to give it another try someday but that would be later this year maybe even as far as holidays since I'm busy with other projects.

I really hope some generous soul out there would pick this up before that🥺

[carlos-zamora]

Copied over from #17484:

Windows Terminal version

1.20.11381.0

Windows build number

10.0.22631.3737

Other Software

No response

Steps to reproduce

1. Close all Windows terminal windows
2. Make test.cmd with the contents pause
3. Open test.cmd with Windows terminal
4. Change focus to a different application like Edge
5. Press the Windows key and r, then type wt
6. Moving the mouse back to the edge window may contribute to reproducing this

Expected Behavior

The new terminal window is on top and has focus.

The expected behavior happens if you skip step 3.

Actual Behavior

Sometimes the new terminal window is behind and does not have focus. The terminal icon in the dock is red.

[carlos-zamora]

Copied over from #18560:

Windows Terminal version

1.22.10352.0

Windows build number

19045.5371

Other Software

PowerShell 7.5.0 clink for cmd.exe

Steps to reproduce

With both of my Windows 10 machines, Terminal 1.22.10352.0 opens up behind other windows when launched from the "Open in Terminal" context menu. This appears to be the same issue or very similar to the now-closed 16260. When launching from the Start menu, it behaves normally, starting above other windows. Both behaviors are completely repeatable, not intermittent.

Reinstalling 1.21.10351.0 fixed the problem on both Windows 10 machines.

My default profile uses PowerShell 7.5.0, but this also happens when cmd.exe is the default.

My one Windows 11 machine does not do this.

Expected Behavior

Expected behavior is for Terminal to open up on top of other windows both when launched from the "Open in Terminal" context menu and when launched from the Start menu.

Actual Behavior

Terminal 1.22.10352.0 incorrectly opens up behind other windows when launched from the "Open in Terminal" context menu, and correctly opens up on top of other windows when launched from the Start menu.

[brknsoul]

Windows Terminal version 1.22.10731.0

Windows build number Microsoft Windows 10 [Version 10.0.19045.5608]

Other Software PS 7.5.0 Python 3.10.11 WSL2

Steps to reproduce Right-click on a folder background > Open in Terminal

Expected Behavior Terminal should open on top of other windows, as it's a newly spawned window.

Actual Behavior Terminal opens behind the window of the folder that spawned it.

[God-damnit-all]

Also having this issue on Windows 10 when I have the "Allow Windows Terminal to run in background" option disabled. When it's enabled, it receives focus properly.