[browser] WasmAppHost should not force COOP/COEP when not using threading

[jeromelaban]

Description

When running an app using the WasmAppHost, the server forces COOP/COEP:

https://github.com/dotnet/runtime/blob/f87428bdd39418a758d916bd950b82e3ee69835f/src/mono/wasm/host/WebServerStartup.cs#L91-L99

This causes issues for apps that don't need this particular feature.

Reproduction Steps

Create an browser wasm app, then add a img that references a non-compatible image.

Expected behavior

The image displays when starting the app from VS.

Actual behavior

net::ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep 200 (OK)

Regression?

Not sure.

Known Workarounds

None, since the headers are set unconditionally:

https://github.com/dotnet/runtime/blob/f87428bdd39418a758d916bd950b82e3ee69835f/src/mono/wasm/host/BrowserHost.cs#L124-L131

Configuration

9.0.100

Other information

No response

[dotnet-policy-service[bot]]

Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.

[pavelsavara]

I guess it creates a problem when your application is also trying to call services on other domains ?

What would be good fix ?

• CLI option to opt-out or opt-in
• set COOP to * domain, is that possible ?
• only use COOP when we know that we are targeting MT, does the host have ability to read MSBuild properties ?

[jeromelaban]

I think a CLI option would be best, driven by:

https://github.com/dotnet/runtime/blob/7f1f23a9f90d08b88de38bfc6990806e011be676/src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets#L27

Allowing COOP to be enabled when threading is used.

[maraf]

In Blazor's version of DevServer we went with additional arg in RunArguments when WasmEnableThreads=true. The only problem is when the property is passed to run from cmd, not csproj, like dotnet run -p:WasmEnableThreads=true, because msbuild doesn't evaluate the property correctly. But I believe this is not the common use case here. We can implement the same pattern here as well.

[premiaware]

if the solution is to be inserted in the project the line: <WasmShellEnableThreads>true</WasmShellEnableThreads>

then i think my app will never run on "azure static web app" again and i will have to stay on .net 8 at the moment.

even using these settings in the file staticwebapp.config.json on azure has no effect, and even changing the app settings on azure will not work

    "Cross-Origin-Embedder-Policy": "require-corp",
    "Cross-Origin-Opener-Policy": "same-origin",
    "Cross-Origin-Resource-Policy": "cross-origin"

[maraf]

@premiaware The other way around. If you need multithreading (not supported yet and enabled by WasmEnableThreads=true), you would need COOP/COEP headers, and you would need to setup them on yous production server.

As of now, the dotnet run server (used only in development), adds these headers even when they are not needed.

[premiaware]

excuse me, I do not need

<WasmShellEnableThreads>true</WasmShellEnableThreads>.

currently my app in .net 8 works correctly on azure, without WasmShellEnableThreads = true, but now that i have upgraded to .net 9 it works but not correctly.

https://github.com/unoplatform/uno/issues/18823

Image not work, i must fix the image download from external domain.

[jeromelaban]

@premiaware this issue is only about starting the server using dotnet run and from VS. Publishing through Azure Static Apps will not have any effect and the staticwebapp.config.json configuration will be used instead. If you have issues in Static Apps, this is not related to this issue.