Regression: Blazor InteractiveAuto doesn't work in browser without WebAssembly support after update to .NET 8.0.2

[Andrzej-W]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

@MackinnonBuck It looks there is a regression described by @Evengard in this comment #52154 (comment).

I have just tested my very simple application which was published 2-3 months ago (.NET 8.0.0). It has a few pages rendered on the server (SSR) and a "counter" page configured as:
@rendermode InteractiveAuto
I don't know if it is important but server doesn't support web sockets - Blazor fallbacks to polling in server interactive mode.

Old version worked correctly in Firefox with javascript.options.wasm disabled. WASM files were not loaded and the application was running in server interactive mode. Then I enabled the javascript.options.wasm option and refreshed the page. The WASM files were loaded and the application worked in client interactive mode.

Currently (in .NET 8.0.2) "counter" page is prerendered on the server and displayed in the browser but browser displays this message in console:
Uncaught (in promise) Error: This browser does not support WebAssembly.

In my opinion for pages (or whole application) configured to work as InteractiveAuto you should use server interactive mode if WASM is not available.

You can go even further. Let's assume my WASM application is published with support for SIMD instructions (this is default configuration in 8.0). Unfortunately they are not available in iOS 15.x. You should test for SIMD support and fallback to SSI mode in case it is not supported. Related issue: #48756

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[Evengard]

Thanks for opening this issue, I wasn't sure if I should.

[javiercn]

@Andrzej-W thanks for contacting us.

In my opinion for pages (or whole application) configured to work as InteractiveAuto you should use server interactive mode if WASM is not available.

It is fair, it's also probably not a common occurrence. The best case I can think of for this is a company disabling wasm via a group policy or similar mechanism.

You can go even further. Let's assume my WASM application is published with support for SIMD instructions (this is default configuration in 8.0). Unfortunately they are not available in iOS 15.x. You should test for SIMD support and fallback to SSI mode in case it is not supported. Related issue: #48756)

This falls out of our support policy as per -> https://learn.microsoft.com/en-us/aspnet/core/blazor/supported-platforms?view=aspnetcore-8.0

[Evengard]

IMHO, any failure to load the wasm app should fallback to SSR. There is one more edge case (which is also probably not a common occurence, but which is probably possible) - when a user ends up somehow with a cleared cache but not cleared local storage . In that case WASM is redownloaded, but no interactivity works until it finished downloading. And during that let's assume that internet broke and the wasm module fails to load (eg we got a bad connection, or we got handed over from WiFi to cellular) - then no interactivity at all will work until the page is reloaded. Looks like JS is checking the existance of some sort of hash in the local storage, and if it is present assumes that the WASM module should be present in the cache as well.

[Andrzej-W]

Hello @javiercn
Regarding WASM/SIMD I understand that it is not a trivial task to support old browsers - we all remember IE. On the other hand iPhone/iPad users cannot simply update Safari to current version without updating iOS and not every iPhone/iPad is compatible with iOS 17.x.

There are a lot of users with iOS 15 or older. See here: https://developer.apple.com/support/app-store/
In this case it would be useful to switch automatically to server interactive mode. Hopefully JavaScript code used to support server interactive mode will be compatible with iOS 15 in the foreseeable future.

[AdamJachocki]

Well this is something really bad. Everyone says that using InteractiveAuto render mode you get the best from two worlds. But it occurs that in reality, when you're using InteractiveServer and interactiveAuto mode, you'll get only InteractiveServer, and the application will never switch to WASM. That's pretty sad.

What's more, state is lost anyway. There is a small pause in debug mode, when... I think that code starts debugger... and then the state is lost.

So it seems that only reasonable way is to use Interactive Server. Correct me, if I'm wrong.

[eliapetrosino]

Hi, do someone know if this one has been solved?
I'll need to choose between theese render modes to make a client company's introducing webapp very soon: if you say AUTO render mode is broken I think I'll go with InteractiveServer in order to achieve more retro-compatibility despite the worse performance and the use case scenario that suggest using WASM instead.

Consider I'm gonna use STATIC rendering for large text sections like OUR MISSION, OUR HISTORY etc (things I do not want to manage inside my db)

Best regards, Elia