[WASM] .NET8 Javascript Interop not working with enabled multithreading (Please use dedicated worker for working with JavaScript interop)

[tobizk04]

If I will use multithreading and async Javascript Interop and it not work in .net8 and wasm.
-> need solution in .net8

I have create a small example project to demonstrate the problem.
It´s a simple WASM app:
-> UnoAppJsMultithreading.zip

The Javascript will called in the ShellViewModel.cs

string jsString = await JsImports.getJsStringAsync();`

if (!jsString.IsNullOrEmpty())
      await _navigator.NavigateViewModelAsync<SecondViewModel>(this, data: new Entity(jsString!));
else
      await _navigator.NavigateViewModelAsync<MainViewModel>(this);

The app calls js function on start of the ShellViewModel.
If you get the string (after 2 seconds) we navigate to the second page and show the string.

This fails with following error:
System.InvalidOperationException: Please use dedicated worker for working with JavaScript interop.

If I try that without multithreading it works.
-> comment out the following lines in the project file:
<WasmShellEnableThreads>true</WasmShellEnableThreads> <WasmShellPThreadsPoolSize>8</WasmShellPThreadsPoolSize>

This shoud be shown:

Have someone a solution for my problem?
Is there any workaround for .NET8.
What is the correct method?

I have tried it with callbacks (js to C#) and syncron js call.
But this is also not working. -> white screen and no error.
-> this is also implement in the solution above. Look at #define WITH_CALLBACK (ShellViewModel.cs)

Have anyone an idea?

Thanks in advance.

[ebariche]

See : dotnet/runtime#85592 and unoplatform/Uno.Wasm.Bootstrap#799

[tobizk04]

Thanks we found the workaround.
Use for all interop calls to JaveSricpt the MainThread works.

I am waiting for the introduction of .net9.
Hopefully they will support multithreading for interop.

[jeromelaban]

Indeed, threading may be working better in net9, and invoking code on the UI thread is needed.

The error in unoplatform/Uno.Wasm.Bootstrap#869 is the same, though you can't really change uno.extensions code, we'd need to change that as well, but the synchronous threading interactions of logging make it more difficult at this time and we may still need to wait for the runtime to fix this.