ExecuteScript synchronous

[omegakode]

I think it would make sense, if you need to work with the return values it has to be synchronous, otherwise is very messy.

AB#25510588

[david-risney]

Thanks for the feedback!

To run script we must go cross process to the renderer process and run the script and so ExecuteScript really is asynchronous. A synchronous version of ExecuteScript would be a wrapper that would call the asynchronous method and then block until it completes. We could block while waiting for the async execution but our partners vary on what should happen while waiting (process just windows messages, process window messages & COM calls, some other set of CoWaitForMultipleHandles flags). Additionally our control is intended to run on the UI thread and we generally don't want to encourage blocking the UI thread or associated reentrancy issues. Accordingly, we've avoided making synchronous versions of our asynchronous functions.

How would you want to deal with reentrancy and what sort of things would you still want to process while synchronously waiting for the async operation to complete?

[ysc3839]

A solution is to use WinRT's IAsyncOperation, but it may not compatible with Windows 7.

[omegakode]

How would you want to deal with reentrancy and what sort of things would you still want to process while synchronously waiting for the async operation to complete?

It should be intended for small js function calls so i guess i should behave like any other function of the main thread, but i understand the complexibility.
Currently i launch a message loop that exits when i post a custom message in the event handler.

[ahmed-salem-me]

Thanks @champnic , I think its absolutely sensible to have a synchronous way of executing web-code as I explained in #2741 , when consumers of webView2 already have code running sync.

I don't want to get in depth of what you're doing, but why not have a wrapper that uses the same hack suggested by some people by using the DispatcherFrame?
I don't think you should block the UI thread, as animations/etc could be running.

[ahmed-salem-me]

@david-risney @champnic , I just noticed this has been open for 2 years!
What does Microsoft suggest as a reliable work around?
I now realized the hack that uses the DispatcherFrame which seemed to work, seems to terminate the process when the call originated from JS using a host object. same as this question:
https://stackoverflow.com/questions/73038854/issue-in-calling-script-synchronously-from-webview2-in-wpf

I've already put a lot of effort and time to replace the web control we use with WebView2, and now it seems I can't proceed! :( that's a real shame

[ahmed-salem-me]

We have big framework called OpenSilver http://github.com/opensilver/opensilver
and we have what we call a simulator, that allows it to run within a desktop app using a web browser control

[david-risney]

Yes the issue is there's no good solution that will work for everyone.

1. If you run WebView2 on the same UI thread as the rest of your app code you'll need to run a message pump so that the script execution completion window message can be delivered to the WebView2 and the WebView2 can complete the async call. Running a message loop like this has potential problems like reentrancy or out of order messages. Though depending on your app perhaps this isn't a problem.

2. Or if you can run the code that is calling WebView2.ExecuteScriptAsync from a different thread than the WebView2 UI thread, you can use normal sort of multi-threading options to block on the caller thread waiting for the async call on the WebView2 UI thread to complete and signal the calling thread.

(2) is more reliable but the constraint of running code on a different thread isn't practical for most folks. (1) may work if you don't run into the issues I described above.

[ahmed-salem-me]

Thanks @david-risney, Yes I just tried the second option, but unfortunately it doesn't solve the issue when the call to ExecuteScriptAsync originated from JS runtime through a host object, cause that happens on the UI thread
similar to this issue
https://stackoverflow.com/questions/73038854/issue-in-calling-script-synchronously-from-webview2-in-wpf

Our entire framework runs by talking to browser control, so it should work fine on a different thread except for what I just explained.

I don't really understand the first option probably lack of deeper knowledge on my side. and you already say it has potential problems.
you say "if you run webview2 on the UI thread", is there a way to run it on a different thread? is that by creating the entire window and opening on a different thread and will that solve this problem?

[ahmed-salem-me]

an example:
class ABC { public GetBoxText() { return webView2.ExecuteScriptAsync("box.value");} }
webView2.CoreWebView2.AddHostObjectToScript("abcObj", new ABC()
from JS
anotherBox.value = chrome.webview.hostObjects.abcObj.GetBoxText();

using a DispatcherFrame in this scenario seems to terminate the process

[david-risney]

In the above you have anotherBox.value = chrome.webview.hostObjects.abcObj.GetBoxText(); but that seems to be mixing async proxy and sync proxy semantics. Do you actually mean one of the following:
a. anotherBox.value = await chrome.webview.hostObjects.abcObj.GetBoxText();
b. anotherBox.value = chrome.webview.hostObjects.sync.abcObj.GetBoxText();

(b) won't work because AddHostObjectToScript synchronous proxies don't support reentrancy. When in JS you call hostObjects.abcObj.GetBoxText(), the JS engine blocks execution to wait for GetBoxText to complete. While the JS engine is blocked waiting for GetBoxText it cannot run additional JavaScript.

(a) I would think should work but I don't know if we've explicitly tested that.

[ahmed-salem-me]

this doesn't work