OSPlatform support for WASM/Blazor

[terrajobst]

For WASM, we need to provide the capability to do runtime checks, which means we should provide an OSPlatform entry for it:

namespace System.Runtime.InteropServices
{
    public partial enum Architecture
    {
         Wasm
    }
    public partial struct OSPlatform
    {
         public static OSPlatform Browser { get; } = new OSPlatform(nameof(Browser));
    }
}

@dotnet/fxdc @marek-safar @mhutch @lewing @SteveSandersonMS @danroth27

[davidfowl]

Seems like the wrong check. WASM inside and outside of the browser will have different capabilities

[terrajobst]

So what would you suggest we do? I can see two options:

• Two generic platforms: WasmInBrowser and WasmOutOfBrowser
• One generic platform for all browsers (WasmInBrowser) and host specific platforms for out of browser (such as WasmNodeJs, WasmElectronJs)

Thoughts?

[davidfowl]

Should the browser be the OS here, forgetting WASM? Then when we understand WASM out of the browser we add that?

[terrajobst]

Should the browser be the OS here, forgetting WASM?

Maybe, but this would mean that code that needs to #if for Blazor would have to detect all browsers, which seems fragile. We could, of course, expose a new API IsBrowser and use that but I'm not sure I like that more.

[marek-safar]

Should the browser be the OS here

To me, the analogy is that WASM is the architecture and the browser is the OS.

    public enum Architecture
    {
        X86 = 0,
        X64 = 1,
        Arm = 2,
        Arm64 = 3,
+		Wasm = 4
    }

    public readonly partial struct OSPlatform
	{
+		public static OSPlatform WebBrowser { get; } = new OSPlatform(nameof(WebBrowser));
	}

Blazor would have to detect all browsers

Why would Blazor have to detect all browsers? If that's for a specific feature we could add the to RuntimeFeatures (e.g. IsThreadingSupported).

What we didn't solve though is how will one get the underlying OS for WASM. We had few requests for that info already, see mono/mono#18627

[SteveSandersonMS]

Having a way to know you’re in a browser, as opposed to some other WebAssembly environment, makes sense. Marek’s scheme above sounds good to me.

Just want to clarify for anyone who might think we want to say which browser or host OS you’re in (eg differentiating Chrome vs Firefox, or Firefox on Windows vs Firefox on Android, or a specific browser version number), I think that should be an anti-goal. We should not try to do that because (1) it’s widely accepted to be a bad idea to infer feature support that way compared with actual feature detection, and (2) browsers are increasingly locking down such info on privacy grounds. Even if we had a way to do some of that today, we should expect that browsers may stop providing such info in the future. It’s better just to say “some browser”.