New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for async functions/Promises in ExecuteScript #416
Comments
Can you share some more details about your scenario/code? Are you doing this entirely on the javascript side? Does you code work in the browser (not in a webview)? |
The result is always '{}'. I have tested the javascript on the console side of browser and it seems to be working just fine but not in webview2 ?? |
A quirk of ExecuteScript (and the underlying CDP call) is that objects are often just returned as "{}". Try wrapping your return value in a .toString(). |
We're tracking improvements here as part of #105. |
Async functions always return promises, .toString has just proved that. I couldn't get any data no matter what i try.
This way i'm getting some data but not all of it. On the other hand, i have tested this ajax script on the console side of the browser and it worked there. Any ideas ? |
Ah, I understand now. We don't currently support async function results in ExecuteScript. It looks like there's a path forwards for implementing support there, so I'll open a feature request on our side to track that. As a workaround, you should be able to use window.chrome.webview.postMessage(data) and add_WebMessageReceived to get out the data from inside your "then" function with the result. Let me know if that work. |
The ajax method is working. I noticed that certain unicodes are causing wcout to fail. I managed to print whole data by using |
I believe the ajax is working because you are making it a synchronous call - I don't think we'd recommend this, as it will block the web code while executing. postMessage when the async calls are complete is preferred. Can you share the code that is doing the character replacement? When you say NULL do you mean the return string is "null" or that the return string is a nullptr/NULL/0x0? |
I don't need async for the project i'm working on, so it's ok for me.
I mean the return string is "null". Replacing or removing any '\u0000' is causing this phenomenon.
|
A "null" string can be returned when the javascript object is undefined, there's an exception in the script, or if there's an error in trying to serialize the result using JSON. I'm not sure why removing the null character would cause those. Can you confirm that code works in the console/browser? |
Yes, it is working without any problem. |
Are you able to share what the |
It's not a static string. The |
Working on getting a repro. Are you able to share the url you are using in you ajax request? Does the problem still happen without the .replace(...) call? |
The url isn't static either. The problem is happening with the |
I think this is very important. Since WebView2 is rolled out with the new Office 365 it will be more interesting as a replacement for CEF/CefSharp. Maybe you can have a look at their interface. Solving the problem similar would probably help when migrating the code from CEF to WebView2! |
I've been struggling all day with trying to await ExecuteScriptAsync on an async javascript function. As soon as it hits the await inside the JS function, it returns to the .NET code. Is there no way to wait for the async JS code to finish before moving on? |
Currently no - the ExecuteScript function doesn't wait on async javascript functions. That's what this feature request is tracking. You can use host objects or postMessage/WebMessageReceived to message a result back to the host app if needed. |
OK, hopefully it gets added soon. Using a callback/post-back defeats the purpose of "await". |
I wonder if anyone could provide a complete working example for this problem using WebView2 We are working with the WinForms/C# integration and we plan to embed a serverside Blazor application. Like described in the docs we shall use For sake of simplicity let's use the JavaScript private async bool ExecuteHasUnsavedData()
{
var received = false;
var result = false;
void OnMessageReceived(object _, CoreWebView2WebMessageReceivedEventArgs args)
{
var msg = args.TryGetWebMessageAsString();
if (msg.StartsWith("RETURN|"))
{
result = bool.Parse(msg.Split('|')[1]);
received = true;
}
}
_webView2.CoreWebView2.WebMessageReceived += OnMessageReceived;
// Assume this is our async JS call which was rewritten so that it uses postMessage to populate it's result
var jsCode = "setTimeout(() => window.chrome.webview.postMessage('RETURN|true'), 2000)";
await _webView2.ExecuteScriptAsync(jsCode);
while(!received)
Application.DoEvents();
_webView2.CoreWebView2.WebMessageReceived -= OnMessageReceived;
return result;
} but that didn't work. Would be really nice if anyone has a suggestion otherwise i'm afraid we're not able to use WebView2 currently 😢 |
Technically this is possible already via the For ease of use I've just released WebView2.DevTools.Dom to nuget.org It's a await webView.EnsureCoreWebView2Async();
// Create one instance per CoreWebView2
// Reuse devToolsContext if possible, dispose (via DisposeAsync) before creating new instance
// Make sure to call DisposeAsync when finished or await using as per this example
// Add using WebView2.DevTools.Dom; to access the CreateDevToolsContextAsync extension method
await using var devToolsContext = await webView2Browser.CoreWebView2.CreateDevToolsContextAsync();
var meaningOfLifeAsInt = await devToolsContext.EvaluateFunctionAsync<int>("() => Promise.resolve(42)"); |
If anyone is just interested in invoking async Javascript via DevTools interface, i just created a little helper class which might point you to the right direction. If you need extended functionallity i can really recommend the library WebView2.DevTools.Dom, thanks @amaitland for creating this! And also thanks for the great hint 🚀 |
Is there a way to read data as text from a blob url ? I've tried executing async/await javascript but i couldn't make it work for blobs.
AB#28965236
The text was updated successfully, but these errors were encountered: