"window.external" evaluation in WebBrowser control gives error "Unexpected call to method or property access."

[rummelsworth]

• .NET Core Version: .NET 5.0.101

• Have you experienced this same bug with .NET Framework?: No.

Problem description:

As of .NET 5.0, the “window.external” object reference that’s intended to provide access to the WebBrowser.ObjectForScripting property value does not work. It worked in .NET Core 3.1.

I didn't find any information about this behavior in the .NET 5 documentation for Breaking Changes or Known Issues.

Evaluating “window.external” in the control’s browser environment produces the following error message:

“Unexpected call to method or property access.”

Here’s a screenshot of the error:

Expected behavior:

A "normal" message box should show (with the message "called from script code").

Minimal repro:

https://github.com/rummelsworth/WebBrowserControlTutorial

The above-linked repo is an implementation of the WebBrowser control's "2-way communication" tutorial. It has 3 branches:

• One branch targets netcoreapp3.1 and does not reproduce the error.
• The main branch targets net5.0 and reproduces the error.
• Another branch also targets net5.0 but has been migrated to use WebView2 instead of WebBrowser.

[merriemcgaw]

Hi @rummelsworth , how blocking is this issue for you? Our strategic recommendation here is a migration to the WebView2 control, though we recognize there isn't full parity yet. How high of a priority is this for any apps that you are migrating?

@Olina-Zhang can you help us narrow down when this issue broke? Perhaps by testing against a few different previews/RCs of the .NET 5 release (don't do too many) but since we've been cleaning up COM Interop for several Previews and we should narrow it down and then @RussKie can investigate which commits may have regressed it.

[Zheng-Li01]

@merriemcgaw, verified the issue which can reproduce on 5.0.100 preview.7.20366.6, can't reproduce on 5.0.100 preview.6.20318.15. please see below screenshot.

[rummelsworth]

@merriemcgaw I'm not sure if this is blocking for us, because we're trying to migrate the affected control to WebView2 today. I expect/hope it'll work fine, since our control and its use of WebBrowser doesn't seem to be very complex. Things look good so far.

To answer the priority question: Not a very high priority for us. If WebView2 works out right now, we're good to go. If not, we have ideas for non-code workarounds in the QA workflow this affects.

Further context, if useful or needed: Our app is a .NET Framework 4.8 desktop app being migrated to a .NET 5+ Blazor Server web app. The last planned public release of the former happened mid-2020. Since it's on Framework, everything's fine there w/r/t WebBrowser. With our migration to a web app (to be released early 2022), the domain "core" of the app is being migrated to .NET 5, and we're trying to limp the old WinForms desktop UI along with gentle .NET 5 migration work so that our internal users can still use and test the analysis engine that the web app is also using, while the web app is still in a not-very-usable state.

[merriemcgaw]

@Zheng-Li01 's investigation can help us determine where the problem is on our end. Glad this isn't a dealbreaker for you at the moment, but we will get to it in .NET 6 I'm pretty certain. Exciting to use the new WebView2 control!

[RalphLAtGitHub]

It would be very helpful if the problem could be solved in .NET 5 and not at the end of 2021. This also eliminates the need to switch to WebView2 immediately.

[RussKie]

I bisected it, and it looks like we regressed in #3388.

@weltkante looks like not all ComVisible attributes were incorrect after all.

[weltkante]

it looks like we regressed [...] looks like not all ComVisible attributes were incorrect after all.

I've looked at it, and its not a regression, the repro code is just badly written. It reuses the Form as ObjectForScripting and relies on it to "just work out somehow".

It worked on Desktop Framework because it had a type library which made Form support IDispatch (which basically allowed the javascript to call back into the form subclass via reflection). On .NET Core the decision was (after much discussion) that you do not want to create your own type library (not supported by .NET Core runtime out of the box anymore, requires manual work), and that you do not want to depend on the type library of Desktop Framework (would have required to maintain the shape of classes as they were on Desktop). As such accessing WinForms objects from native code was deprecated.

As a result the sample code can no longer hijack the Form base class for making all member functions visible (which IMHO is bad practice anyways). ObjectForScripting should be a user-declared object which supports IDispatch. (Note that I omitted all interop annotations because the defaults are just right for it to work out. If you changed the defaults in your project or want to be explicit about it you can of course annotate with the appropriate COM interop attributes.)

public class MyScriptObject
{
    private Form1 _form;

    public MyScriptObject(Form1 form)
    {
        _form = form;
    }

    public void Test(string message)
    {
        MessageBox.Show(message, "client code");
    }
}

webBrowser1.ObjectForScripting = new MyScriptObject(this);

Alternatively, if you insist on the Form to handle scripting you can declare an interface with the methods to expose:

public interface IForm1
{
    void Test(string message);
}

[ComDefaultInterface(typeof(IForm1))]
public partial class Form1 : Form, IForm1

[rummelsworth]

The ComDefaultInterface approach is very attractive. It seems like a strictly additive and declarative "light touch", perfect for our specific situation. It'd be great if @weltkante's suggestions were added to the WebBrowser 2-way communication tutorial (the same one used in the repro) or made visible in the docs in some other way.

Not that the rest of our story is very important, but the WebView2 migration worked out well. It seems like it could've been a lot trickier than it turned out to be, with the potential complexity of converting sync call sequences to async call sequences with captured local state, but the conditions in our code "degenerated nicely" (feels like a funny thing to say). We had (a) only a few interop calls on either side and (b) only one non-tail interop call.

[RussKie]

Thank you @weltkante.

@rummelsworth do you think we can close the issue?