Hello, I would like to request that when Chromium-based WebView2 launches its separate web process, it should launch the separate web process in the same desktop (HDESK) as the app using WebView2, not always in the default desktop.

I suggest that before WebView2 launches the separate web process, it should (if necessary/applicable):

1. Invoke the Win32 GetThreadDesktop function in order to determine which desktop the current app is running inside.
2. Launch the separate web process in the same desktop as what GetThreadDesktop returns, by invoking the CreateProcessWithTokenW or CreateProcessAsUserW function. Set the STARTUPINFOW.lpDesktop field of the struct passed to the lpStartupInfo parameter of CreateProcessWithTokenW or CreateProcessAsUserW.
3. Consider also invoking GetCurrentProcessToken at the same time as GetThreadDesktop, in order to help prevent another bug where WebView2 would fail when the app is run as a different user, such as when the app is run as administrator. i.e. WebView2 should launch the separate web process with the same user/access token and same desktop as the app using WebView2.

Ideally, WebView2 should also not care (not fail) when Windows Explorer ("explorer.exe") is NOT running in the desktop where the app is running. For example, if the app using WebView2 runs in a desktop named "TestDesktop1", then the separate web process should be launched in the same desktop "TestDesktop1", and ideally WebView2 shouldn't malfunction if NO instance of explorer.exe is running in "TestDesktop1".

I don't know whether WebView2 will launch the separate web process directly or indirectly via a broker process such as explorer.exe. The EdgeHTML-based WebView communicates with explorer.exe. If WebView2 will also communicate with explorer.exe, then the desktop and user/access problems exist. On the other hand, if WebView2 will simply and directly the launch the separate web process by itself (without going through explorer.exe or other broker process), then I believe the desktop and user/access problems would be correctly handled automatically without any extra work required to make it function correctly. Whereas if a broker process is used, then I think care needs to be taken to ensure that the separate web process is launched with the same user/access token and same desktop as the app using WebView2.

In comparison, the EdgeHTML-based WebView has a problem with multiple desktops: It fails when the app is running in any non-default desktop because EdgeHTML WebView always launches the separate web process in the default desktop. I have written more details in the bug report #1384 "WebView launches separate process in wrong desktop (HDESK)"