Make subsequent windows open in the foreground

[flyingcat]

Sometimes subsequent WT windows open in the background behind other applications. This PR tries to fix it.

Refs #15895
Refs #15479

Mysterious bug (and annoying). There are even some discussions about happening to the first startup, not just subsequent ones. Sometimes the window may show up without animation too. So I don't think this is the final solution, but it did get solved on my computer, for now.

Validation Steps Performed

0. Quit all WT windows if some.
1. Open File Explorer, click "Open in Terminal" in context menu.
2. Move the newly opened window and minimize it.
3. Back to step 1 and repeat several times.
4. All the windows should open in the foreground correctly (yet possibly without animation).

[zadjii-msft]

You know, I never had a super good repro for this. That being said - this is what we all assumed the fix would be. So if this does work for you, then I'm guessing this was the fix after all!

[zadjii-msft]

Thanks for doing this! We'll make sure to send out the first Canary build with this to the linked threads, to see if that sorts everyone else out too.

[flyingcat]

Figure it out. When close one of the minimized WT window from taskbar, then subsequent windows will show up without animation. Latest win10.

I believe that there is one or more problems deep down in the complex window initializing and win32-xaml architecture.

[flyingcat]

Also, subsequent (peasant?) processes will call xaml::Hosting::WindowsXamlManager::InitializeForCurrentThread(), which is unnecessary. If we somehow cache the value of _app.Logic().IsolatedMode(), call to ReloadSettings() is unnecessary too. This will save about 100ms + 15ms on my computer.

[tusharsnx]

I'm so glad that @flyingcat brought this up. I was on this ever since #17168, and I believe this PR fixes some missing focus cases:

1. Launching new window/tabs using shell extension (right click menu of Explorer).
2. Launching terminal by running wt.exe from the Run dailog.

You can see the similarty here, both will lead to an indirect launch of a new WindowsTerminal.exe window if it was running already. The WT process is a bg thread in both these cases so it won't receive window focus automatically by the system.

---

For the core team:

@zadjii-msft Just to reiterate on this:

You know, I never had a super good repro for this.

My simple repro is to:

1. Confirm "New instance behavior" is set to "Create new window".
2. Open WT,
3. Drag and move the window to a different location (just so that windows sees the user has interacted with the window),
4. Click on the desktop (so that the window loses focus = WT is now a background thread/process), and then
5. Launch another WT window using explorer's right click menu or Run dailog.

Defterm needs a similar fix, and I believe that would solve all missing focus scenarios. When a new defterm request is received and there's a running instance of WT on the system, the window is created by a WT thread that doesn't satisfy any requirements listed for SetForegroundWindow(). The foreground privilege needs to be sent down from Conhost to openconsole.exe to the running instance of WindowsTerminal.exe because in that moment only Conhost was the new process that was created by the foreground application (Windows shell).

[DHowett]

Defterm needs a similar fix, and I believe that would solve all missing focus scenarios. When a new defterm request is received and there's a running instance of WT on the system, the window is created by a WT thread that doesn't satisfy any requirements listed for SetForegroundWindow(). The foreground privilege needs to be sent down from Conhost to openconsole.exe to the running instance of WindowsTerminal.exe because in that moment only Conhost was the new process that was created by the foreground application (Windows shell)

So this one, at least, I did implement in Windows - plumbed all the way through stage 1 and stage 2 defterm handoff - and found that it made little difference. Conhost itself may not have foreground rights, technically, until it does some NTUSER magic that we haven't fully discovered. I can't remember which of the four calls in the chain failed.

[flyingcat]

I just want this bug get fixed.

Oh, I realized it may sound like a boss ask someone to finish something with no executes (they often do). That's not what I mean. I saw some commits have co-authors, so I think it's the team members add changes before merging, never thought of this ping-pong way. Also I don't care I am a contributor or not.

---

If this or anything else get merged, can it back port to 1.20 branch? I really want to solve this problem, as it perfectly break my usage scenario.

[DHowett]

thanks you for doing this!