JavaScript calling .NET Async Method with Return Value on HostObject fail to return correct Value

[RickStrahl]

I'm trying to call back from JavaScript into .NET using a Host object registered into the document. In experimenting I'm finding inonsistent behavior with the object registered.

For my test class I have:

  [ClassInterface(ClassInterfaceType.AutoDual)]
    [ComVisible(true)]
    public class DotnetInterop
    {

        // asyn just because
        public async Task<string> HelloWorld(string name)
        {
                   await Task.Delay(200);
                   var res = $"Hello World, {name}! - Message: 'This text was retrieved from .NET and shown here in JavaScript.'\n" +
                      "Button click in .NET -> JavaScript Function calls Hello World in .NET -> Returns message to JavaScript";
            return res;
        }
        ...
}

Then during init:

webView.CoreWebView2.AddHostObjectToScript("mm", Interop);

Now when I call this from JavaScript like this:

async function callHelloWorldDotnet(name) {
    // .NET object reference (async)
    var msg = await window.chrome.webview.hostObjects.mm.HelloWorld(name);
    alert(msg);
}

I get a 'null' result. Also tried a promise directly. The .NET method gets called and returns a result, but the client is not picking it up as an async function or via a promise. If I return a promise the promise says pending.

Now I can get this to work by changing the method to a non-async method:

public string HelloWorld(string name)
{
    var res = $"Hello World, {name}! - Message: 'This text was retrieved from .NET and shown here in JavaScript.'\n" +
              "Button click in .NET -> JavaScript Function calls Hello World in .NET -> Returns message to JavaScript";
    return res;
}

Now using that same client side code works. It also works with sync from the client. Both of these work (in their respective async/non-async function contexts):

// sync
var msg = window.chrome.webview.hostObjects.mm.sync.HelloWorld(name);

// async
var msg = await window.chrome.webview.hostObjects.mm.HelloWorld(name);

Summary:

• I can call the method both sync and async from JavaScript if .NET Method is not async
• I can call the method both sync and async from JavaScript if the .NET is async and no value is returned (fire and forget)
• I cannot call the method either async or sync from JavaScript if .NET method is async and returns a value

Question: When do we need Async .NET Host Methods?

My question is when the client is calling the host using the async instance shouldn't the method calls on the host object be async as well or at least be supported as async?

All of this feels very inconsistent, but it's not clear if this is by design or a pre-release bug...

In my actual application for now I've been avoiding async calls for results that return values, because I needed it to work both with WV2 and WebBrowser so I use sync. However, in my test form which is green field I can use aysnc through all of it and expected the called methods also to be async.

Note it looks to me that the methods fired are getting invoked as async methods - meaning the code in the async methods executes as it should with async semantics. But the results are not picked up as TASK based async values and returned as is rather than fixing up the async call.

Either way a clear answer on how this is supposed to work would be helpful.

Desired/Expected behavior:

• If using the .sync object from JS call with sync semantics
• If not use the .sync object from JS call with async/await semantics both on client and host

[champnic]

Thanks for the detailed summary @RickStrahl. This is a known limitation that async .NET functions aren't currently supported. We are tracking support in #75, but there's also a potential workaround here (if changing the .NET functions to sync doesn't work for you):
#75 (comment)

[RickStrahl]

So what is the point of having an async object if it doesn't actually work async?

[champnic]

Do you mean the JS projection, window.chrome.webview.hostObjects.<object>? That's currently async by default as it's a cross-process call back to the host app.

If you mean the .NET host object, there's currently no point in it being async until we add support.

[RickStrahl]

Yes that's what I'm talking about.

The problem is that you can't return a value from an async call into .NET from JavaScript. You can call from JavaScript to .NET sync and get a result, but async - no. The call is always async capable, but you can't actually await it on the JavaScript side because the result is a pending promise that never resolves (unless this was fixed recently).

It runs async, but if you want a result back (which is why you'd need async in the first place) then you're out of luck.

I don't understand how the sync calls can work and async won't. If the calls are out of band (they have to be because OOP) then code has to wait for completion no matter what. I don't see how this can not be wired up into a working promise interface since it works for the sync call?

On my end this bug is causing a lot of problems because it breaks the async chain in .NET. The only way I can handle a .NET method that returns a value I have to make the method sync or it won't work to return that value. If I now need to make an async call inside of that called code I don't have a way to do this cleanly because the async chain is broken. My only workaround here then is to work with potential deadlock prone .GetResult() calls (which will trigger deadlocks frequently in my scenario).

Bottom line - I think this would be a worthwhile thing to fix. For behavior like I describe, but also just for pure consistency. Having an interface that works async but fails to return a proper async result is just broken.

[champnic]

Ok I think we're in agreement. If the .NET host object has an async function that's getting called, that's what's currently broken (and as you mentioned, has dangerous workarounds). That is the support we are planning on adding in #75 - I've updated the title to make it more clear. That issue has been open for a long time, so I'll see if I can bump the priority and get a better sense from the team if it's something that wouldn't be too expensive to implement. Thanks!

[RickStrahl]

@champnic Finally coming back to this to see if I can make async calls work and I don't seem to be able to call a method async without problems.

Same code works sync, but asycn fails.

Here's what I'm doing:

dotnetInterop: {
    // return async instance if available, otherwise sync
    getEditor: function() {  // async instance
      if (window.chrome) {
        // WebView instance does not want to be cached
        return window.chrome.webview.hostObjects.mm || window.chrome.webview.hostObjects.sync.mm;
      }
      return te.mmEditorAsync || te.mmEditor || null;
    },
    getEditorSync: function() {
      if (window.chrome) {
        // WebView instance does not want to be cached
        return window.chrome.webview.hostObjects.sync.mm;
      }
      return te.mmEditor || null;
    },
    // IMPORTANT: Method is async!
    previewLinkNavigation: async function(url, rawHref) {
        //var editor = te.dotnetInterop.getEditorSync();   //  this works if making a sync call
        var editor = te.dotnetInterop.getEditor();
      if (!editor)
        return false;
      try {
        const handled = await editor.PreviewLinkNavigation(url, rawHref);      // <--- boom
        return handled;
      } catch (ex) {   // <-- this doesn't fire when it fails - just silently fails
            return false; 
      }
    },

Then the code that uses this block:

$(document).on("click",
        "a",
        async function(e) => {
            var url = this.href;
            var rawHref = $(this).attr("href");
            var hash = this.hash;

            if (te.mmEditor) {
                debugger;
                var handled = await te.dotnetInterop.previewLinkNavigation(url, rawHref);   // blows up async - works sync
                if (handled) {
                    // it true editor handled the navigation
                    e.preventDefault();
                    return false;
                }
            }
...
        });

The .NET code gets called and it completes properly from the .NET end, but when the call returns the script fails and exits without running any further code (unhandled exception). it doesn't even fire the exception handler around the async call - it just silently fails.

The .NET code called works but just for reference here is the signature:

public async Task<bool> PreviewLinkNavigation(string url, string src = null)
...

await RaiseOnPreviewLinkNavigation(url, src);

...

and I'm passing both parameters in.

This is the same behavior I had months ago when I brought this up. In between I recall you posted (on another thread that I can't find now) that you were able to make async calls. That's not what I see - I tried a similar setup for a few different async calls and they all behave with the same failure - code just fails silently.

In the above my workaround was to wrap the code into a sync call on the .NET end which is highly unreliable but happens to work in this case because this is a rare operation that generally occurs on idle UI state:

 public async Task<bool> PreviewLinkNavigation(string url, string src = null)
        {
            var editor = Model.ActiveEditor;
            return await editor.PreviewLinkNavigation(url, src);
        }
        public bool PreviewLinkNavigationSync(string url, string src = null)
        {
            var editor = Model.ActiveEditor;
            bool result = editor.PreviewLinkNavigation(url, src).GetAwaiter().GetResult();
            return result;
        }

The second one is the replacement to make this work.

It really sucks that:

• WebView forces Async operation for calls into the DOM
• WebView doesn't work with Async calls out of the DOM

I can work with either scenario where both are consistent but with this weird mixed sceneario I'm stuck with a mismatch where some code is sync and some is async and this is really difficult to transition between these states. And it basically forces me to use unreliable code that's very likely to dead lock my application.

We need consistency here. Either make it possible to call into the DOM using sync, or make sure that callbacks from the DOM also properly support async.

To be clear the async failure on callbacks is that the .NET Call works fine, but the JavaScript code fails to resolve the promise (or whatever it is that this Interop layer returns - looks like an unresolved Promise object to me).

It's been a nightmare having to convert my app to use async (because that's the only way I could make the many interop calls into the DOM work), and now to get screwed on the other because calls coming back don't properly work with inbound async.

[RickStrahl]

So I gave this a try with the latest preview runtime component (1.0.1189-prerelease) but not the newer matching runtime, and I still cannot get an async call to return a value.

Here's what I'm doing and seeing.

The following code is called on a click handler to pass through links from the browser to .NET to examine and handle so they open in an external browser or in the appropriate applications or editors.

  dotnetInterop: {
    // return async instance if available, otherwise sync
    getEditor: function() {
      if (window.chrome) {
        // WebView instance does not want to be cached
        return window.chrome.webview.hostObjects.mm || window.chrome.webview.hostObjects.sync.mm;
      }
      return te.mmEditorAsync || te.mmEditor || null;
    },

// ... other methods

    previewLinkNavigationAsync: async function (url, rawHref) {
        var editor = te.dotnetInterop.getEditor();  // get async .NET editor instance
        if (!editor)
            return false;

        debugger;
        try {
            // **** THIS FAILS HERE! Hard fault, `catch` does not fire
            var handled = await editor.PreviewLinkNavigationAsync(url, rawHref);  
 

           return handled;  <--- never gets called
        } catch (ex) {  //   <---- this doesn't fire on the failure
            debugger;
            console.log(ex);
        }
    },
}

The . NET async method code that is called gets fired just fine: I can see it running in the debugger and it's correctly receiving the iinput and correctly returning a value:

public async Task<bool> PreviewLinkNavigationAsync(string url, string src = null)
{
    var editor = Model.ActiveEditor;
    bool result =  await editor.PreviewLinkNavigation(url, src);
    return result;
}

also tried something simpler to make sure there's not some problem with the code called in the background (which uses Shell to open a link):

public async Task<bool> PreviewLinkNavigationAsync(string url, string src = null)
{
    var editor = Model.ActiveEditor;
    await Task.Yield();
    return true;
}

with the same result - the code simply fails silently without firing the catch handler.

You can see the code firing into this method and run up to the await call - stepping F10 over the line then jumps out of the debugger altogether and the external page is opened and navigated (from WPF shell navigation which in my case opens Brave).

[RickStrahl]

Just to make sure there's isn't something funky happening with the async/await support I also set up a raw Promise call:

    previewLinkNavigationAsync: function (url, rawHref) {
        var editor = te.dotnetInterop.getEditor();  // get async .NET editor instance
        if (!editor)
            return false;

        try {
            var handled = editor.PreviewLinkNavigationAsync(url, rawHref);
            console.log(handled);   <!-- promise
            handled
                .then((val) => {
                    console.log('then: ' + val);   <!-- fires but always `null`
                })
                .catch((err) => {
                    console.log(err);
                });
            return handled;
        } catch (ex) {
            debugger;
            console.log(ex);
        }
    },

When I do this then fires, but the result value is always null.

So in summary this is exactly the same behavior I was describing above - I don't see that anything has changed.

[RickStrahl]

Just to clarify some of the scenarios I've tried and what does and doesn't work:

works

• Sync JS call to .NET method - method gets called result works (off of sync host object) - This is useful and really glad this works!
• Async JS call to .NET without result - .NET code gets called this works as there's no result back to JS

doesn't work

• Async JS call to Async .NET method with result - .NET code gets called, but the result is not returned. await calls fail hard in WebView (no error trapping including try/catch not firing).
• Sync JS call to Async .NET method - .NET method is called, but result is null (should be a promise?)

To summarize the problem really appears to be that the WebView2 runtime is not dealing with Task results correctly and failing to translate the Task results back into JavaScript promises.

[champnic]

Hey @RickStrahl - Can you try this with the newer runtime? I just checked the code and I believe it also has changes in the runtime.

[RickStrahl]

This is still not working for me. I'm running:

• 1150 Runtime (Canary?)
• 1189 WebView .NET Component

Where can I get a newer runtime than Canary?

In this code:

$(document).on("click",
        "a",
        async function(e) { 
            var url = this.href;
            var rawHref = $(this).attr("href");
            var hash = this.hash;

            // Notify of link navigation and handle external urls
            // if not handled elsewhere

            if (te.mmEditor) {
                // TODO: Sync call works for now but problematic - should use async but WebView2 bug not working
                //var handled = te.dotnetInterop.previewLinkNavigation(url, rawHref);
                //var handled = await te.dotnetInterop.previewLinkNavigationAsync(url, rawHref);

                debugger;
                var editor = window.chrome.webview.hostObjects.mm;

                var handled = await editor.PreviewLinkNavigationAsync(url, rawHref);

                alert("Handled: " + handled);  // <!-- this never fires

                if (handled) { //te.mmEditor.PreviewLinkNavigation(url, rawHref)) {
                    // it true editor handled the navigation
                    e.preventDefault();
                    return false;
                }
            }
...
        });

If I used an explicit promise:

var handled = editor.PreviewLinkNavigationAsync(url, rawHref);
handled
    .then((result) => {
        alert("Callback result: " + result);   // <!-- always `null`
    })
    .catch(ex => { alert("callback error") });