Manually hide our DesktopWindowXamlSource

[zadjii-msft]

As discussed in #6507

Newer builds of Windows do this automatically. However, this was spotted in the wild on 1.18. It's possible the threading changes created a situation where the OS-side fix no longer applied to us. So let's just do it manually. It doesn't have any side effects.

I saw this once on Win11, but couldn't repro it this morning when I tried to add this fix. I'm just gonna assume this worked, despite the fact that I can't repro it on win11 anymore.

closes #6507

See also #14957

detailed description

WindowsXamlManager::XamlCore::Initialize calls ConfigureCoreWindow, which creates a CoreWindow on the thread

Problem is, we're calling that on the main thread (which doesn't have any windows), and then eventually creating a DesktopWindowXamlSource on a second thread for the actual window

It's not that it "manages a window", it's that it "manages xaml on Windows OS". just use ICoreWindowInterop -- QI for ICoreWindowInterop and call get_WindowHandle.

Also see:

• ICoreWindowInterop
• WindowsXamlManager.InitializeForCurrentThread
• The source code in onecoreuap\windows\dxaml\xcp\dxaml\lib\WindowsXamlManager_Partial.*
• os.2020!6102020 which fixed MSFT:33498969, MSFT:27807465, MSFT:21854264

[j4james]

FYI, I get this DesktopWindowXamlSource thing all the time in the current Dev build of Terminal, and this change doesn't appear to have fixed that. This is on Windows 10 (version 10.0.19045.2728).

[lhecker]

Seems like this needs fixing for & testing on Windows 10. 😟

[zadjii-msft]

Hmm.

These both have the same PID. But that was just a single terminal window, so maybe the _windowsXamlManager = xaml::Hosting::WindowsXamlManager::InitializeForCurrentThread call on the Main thread is also creating a separate CoreWindow...

[DHowett]

Wait, do we need xaml on the emp thread?

[DHowett]

@j4james would you be able to test this on W10 using Mike's unpackaged CI build artifacts? (We can probably also test it ourselves, I admit)

[zadjii-msft]

Actually tested this on Windows 10 in a VM too.

For future self:

Add-AppxPackage -Path path\to\Appx\AppxManifest.xml -register

will register the dev appx for testing. You need to enable dev mode first. You need to actually do that too, so that it'll hook up the MUX 2.8 FWP dependency. (you could do the whole unpackaged thing too, but I haven't gotten far enough to bother with that yet)

[j4james]

I've just tested with these changes patched into my dev build, and it's definitely fixed the issue for me.

[DHowett]

K, let's go then!