[blazor][wasm] Remaining legacy interop

[pavelsavara]

Below is list of usages of legacy interop.

• Usage of BINDING.call_assembly_entry_point

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 68 in 730dac2

    await BINDING.call_assembly_entry_point(assemblyName, emptyArray, 'm');

  • this one is most problematic because it uses eval() which is CSP blocker
• Usage of BINDING.js_string_to_mono_string in invokeJSFromDotNet

  • aspnetcore/src/Components/Web.JS/src/Boot.WebAssembly.ts

    Line 124 in 730dac2

    return resultJson === null ? 0 : BINDING.js_string_to_mono_string(resultJson);

  • aspnetcore/src/Components/Web.JS/src/Boot.WebAssembly.ts

    Line 138 in 730dac2

    return BINDING.js_string_to_mono_string(resultJson);

  • this is potentially just dead code, if the user code doesn't use the obsolete IJSUnmarshalledRuntime
  • but I don't fully understand jsCallDispatcher and invokeJSJson use-cases
• usage of BINDING.unbox_mono_obj and BINDING.conv_string in readStringField which is part of renderBatch

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 127 in 730dac2

    const unboxedValue = BINDING.unbox_mono_obj(fieldValue as any as System_Object);

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 138 in 730dac2

    decodedString = BINDING.conv_string(fieldValue as any as System_String);

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 142 in 730dac2

    decodedString = BINDING.conv_string(fieldValue as any as System_String);

  • this is problematic from GC safety, for which we do have stop-gap solution.
  • this is probably not a problem for CSP as there is no bind/invoke and no eval()
• MonoHeapLock.stringCache is pointer hazard

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 139 in 730dac2

    currentHeapLock.stringCache.set(fieldValue, decodedString);

  • because BINDING.conv_string is already caching interned strings by their pointer (because they never move on GC)
  • any other strings do move and could be even collected, so the pointer could be pointing at different object and produce a) invalid value or b) crash even in single threaded app
  • this is problematic from MT GC safety, for which we do have stop-gap solution.

All of the uses prevent users trimming legacy interop dead code with <WasmEnableLegacyJsInterop>false</WasmEnableLegacyJsInterop>

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[javiercn]

There seems to be some work to be done still here, is that correct @pavelsavara?

/cc: @maraf (in case you know)

[pavelsavara]

Yes, there is.
renderBatch part of it could be related to how we solve multi-threading.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.