Eliminate framework use of 'IJSUnmarshalledRuntime'

[MackinnonBuck]

Eliminate framework use of IJSUnmarshalledRuntime

Removes internal usage of IJSUnmarshalledRuntime to in favor of [JSImport]-style JavaScript interop.

Description

• Added an IInternalJSImportMethods interface that gives us a layer of abstraction over direct calls to [JSImport] methods:
  • Added TestInternalJSImportMethods and updated tests to utilize it
  • Note: The [JSImport] methods that only make sense in an E2E context do not appear in IInternalJSImportMethods
• Updated usage of IJSUnmarshalledRuntime for:
  • Navigation (WebAssemblyNavigationManager and WebAssemblyNavigationInterception)
  • Application startup (WebAssemblyHostBuilder)
  • Hot reload (WebAssemblyHotReload)
  • JSON-based interop (InternalCalls and WebAssemblyJSRuntime)
    • Also improved byte array transfer by removing the existing extra interop call.
  • Rendering (WebAssemblyRenderer)

Contributes to #37787 and #46673

[pavelsavara]

Note there are some E2E test failures. I have not looked into details yet.

[pavelsavara]

As a next step (could be next PR), this could be replaced by promise/Task instead of Begin/End pattern.

[SteveSandersonMS]

Yes that would be good. We did the begin/end thing because it predated support for Task in the WebAssembly runtime's interop mechanism.

[pavelsavara]

I don't know if this is perf critical but if so, it could be re-implemented as passing int[] Ids, string[] assemblies etc.

[SteveSandersonMS]

Good point. However it's only a one-time thing that happens during startup, so my guess is that we wouldn't be able to observe any difference.

[pavelsavara]

In next PR we could try re-invent how the goal of invokeJSFromDotNet could be achieved otherwise.
To ged rid of things like BINDING.js_string_to_mono_string

[SteveSandersonMS]

Is the exception type name still exposed on the JS side somehow? Seems like that would be valuable for debugging.

[MackinnonBuck]

Unfortunately, it looks like that information is lost now. The JavaScript errors that get created from exceptions thrown in [JSExport] methods have a message property equivalent to the C# exception's Message property, which excludes the exception type and stack trace. We could fix this by catching exceptions on the .NET side and wrapping them in a new Exception to simulate the old behavior, like:

try
{
    return DotNetDispatcher.Invoke(Instance, callInfo, argsJson);
}
catch (Exception ex)
{
    throw new Exception(ex.ToString(), ex);
}

Or I wonder if there's a way to address this on the runtime side, perhaps by updating ManagedError to include information about the type of exception that got thrown?

[pavelsavara]

They are just a proxy and could also cross the boundary back to managed.
Collecting stack trace is very very expensive and we do it when you call toString() on it (I think).

[SteveSandersonMS]

Collecting stack trace is very very expensive and we do it when you call toString() on it (I think)

@pavelsavara Does that mean we could change the JS-side code to call throw new Error(exceptionProxy.toString()), and thereby get back the information we had before? Or is there some other mechanism you'd recommend?

[pavelsavara]

no, please don't do that. It would be slow as you would pay the cost of stack trace creation also for exceptions which would be caught and handled silently.

We override the implementation of ManagedError.stack property to provide it on demand.

https://github.com/dotnet/runtime/blob/8d938ec1d18de3211040bccca1ea73f2574dc87a/src/mono/wasm/runtime/marshal.ts#L339

I think error.toString() and console.log(error) would both include stack property (at least on chrome). I'm open to suggestions how to improve it.

Proxy in the other direction is also lazy

https://github.com/dotnet/runtime/blob/8d938ec1d18de3211040bccca1ea73f2574dc87a/src/libraries/System.Runtime.InteropServices.JavaScript/src/System/Runtime/InteropServices/JavaScript/JSException.cs#L40

[SteveSandersonMS]

Note there are some E2E test failures. I have not looked into details yet.

If the E2E tests still pass locally but are timing out in CI, that's likely an unrelated issue which we're currently investigating, and you don't need to block this PR on it. TLDR is that the CI machines auto-updated to chromedriver 110, and we don't yet know why, but this suffers connection issues that were not present in chromedriver 109. Please verify locally though!

[SteveSandersonMS]

Looks great! I really like the improved simplicity.

[MackinnonBuck]

I've validated the hot reload changes locally.

[MackinnonBuck]

I'm going to merge this now and address improvements in a follow-up PR.

[ctigrisht]

I'm going to merge this now and address improvements in a follow-up PR.

Hey, is this available in the latest .NET 8 preview? I want to be able to use CSP security in blazor wasm, thanks.

[ghost]

Hi @ctigrisht. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.