Running host objects on a different thread to avoid hanging app?

[jaredkrinke]

Hopefully I'm missing something obvious, but is there a way to avoid blocking the main thread when executing host object methods/getters?

What I've tried

I'm aware that host objects are exposed via window.chrome.webview.hostObjects.* and window.chrome.webview.hostObjects.sync.*, but neither of those appears to help. Using either one, all calls to methods/properties on my host object come in on my app's main thread, so if they're slow it hangs my app (exactly what I'm trying to avoid).

I'm also aware that there is a chrome.webview.hostObjects.options.forceAsyncMethodMatches option, but this only changes the shape of the method/property's result. The call to my native code still comes in on my main thread.

I can't internally farm the work out to another thread because the host object is synchronous, and it's not possible (as far as I'm aware) to return a promise object directly from my native code.

A bad workaround

Obviously, I could implement some sort of polling, but I'd like to expose a promise-based interface. This doesn't seem possible given the above.

Questions

Any other ideas? Is there an option I need to provide to WebView2 to let it run my host object on its own thread?

The threading model doc mentions "The WebView2 must be created on a UI thread that uses a message pump. All callbacks occur on that thread", but there is no mention of whether all host object proxy calls also must happen on that same thread (although that's how it appears to me).

References

I've read through these pages and am still not seeing a solution:

• https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.addhostobjecttoscript?view=webview2-dotnet-1.0.1370.28
• https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/security
• https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/threading-model
• https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/hostobject?tabs=win32cpp

[jaredkrinke]

I'm starting to suspect that the async host object proxies only exist because JavaScript code and the thread that created the WebView2 are running in different contexts and that the async proxies aren't designed to support slow methods (like I had hoped).

If that's correct, then I guess I will need to create my own async return mechanism (probably based on PostWebMessageAsString and WebMessageReceived).

Edit: After thinking about this some more, it may be possible to pass the resolve and reject callbacks from a JS promise to a host object, run work in a thread pool, post the result back to the main window's thread, and then invoke the appropriate callback. This would avoid having to JSON-encode everything.

[jaredkrinke]

I never found any built-in support for exposing async methods on host objects that actually run async, so...

My solution was to move methods that could be slow to a thread pool and then expose everything as a JavaScript promise by passing resolve and reject from new Promise((resolve, reject) => ... to my native code and marshal the IDispatch interfaces over to the thread pool thread where they eventually get called to resolve or reject the promise.

[lightheart33]

I'm am very impressed you got this to work, I did something similar with CEF3, before WebView2,
and that was quite pain full, but it worked. Long tasks were running in parallel to the main thread,
which I tested with a rotating spinner, without blocking the rendering or user interactions, and upon
completion I called either the promise reject or resolve.

Getting this to work with WebView2 sounds to me a bit complicated,
your statement "... and marshal the IDispatch interfaces over to the thread pool...",
only throws up question marks in my head, perhaps you could provide a little more
information about how to achieve this? :D

[jaredkrinke]

For marshalling the IDispatch interfaces (which are just the native code representation of the resolve/reject callbacks provided by the JavaScript Promise constructor), I used CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream (my code needed to run on Win7): https://devblogs.microsoft.com/oldnewthing/20151021-00/?p=91311

Everything else was just ensuring the code ran on another thread. Disclaimer: the code worked for me in testing, but there are no guarantees it's correct. Here's a link to my code:

https://github.com/jaredkrinke/sic1/blob/master/sic1/client/windows/promisehandler.cpp

My host object definition looks like:

interface IWebViewWindow : IUnknown
{
    HRESULT ResolvePersistPresentationSettings([in] VARIANT resolve, [in] VARIANT reject);
// ...

The TypeScript code looks like:

function wrapNativePromise<TResult, TArguments extends any[]>(nativeFunction: NativePromiseExecutor<TResult, TArguments>, ...args: TArguments): Promise<TResult> {
    return new Promise<TResult>((resolve, reject) => nativeFunction(resolve, reject, ...args));
}
// ...
wrapNativePromise(webViewWindow.ResolvePersistPresentationSettings) // Returns a Promise

[lightheart33]

Thanks a lot, I didn't knew a solution could be that elegant and generic,
I will study it in details and try to understand :D

[BohdanMaslowski]

Update 2024: Direct support for calling async methods on host objects has been added to the SDK (.NET, WinRT): #75 (comment)