[Blazor] Auto Render not working properly in .NET 8 and page locks until WebAssembly start

[AmBplus]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I updated Visual Studio to the latest version 17.8.0 and created a Blazor app using Auto render mode With Dotnet 8. When I run the application and navigate to the Counter tab, the whole page locks up until the WebAssembly Start. I can't do anything or switch to another tab until the download Finished And WebAssembly Start, even though it happens quickly locally. This could cause problems in production where the download may take longer. It also goes against the purpose of Auto render mode.

Expected Behavior

With auto render mode, the page should initially use server-side rendering. Once WebAssembly finishes downloading And Start, it can switch over seamlessly without locking up the page.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

NET 8 , Windows 10-64

Anything else?

As you can see, the page is locked and prevents navigating to another tab.

[danroth27]

The delay is most likely due to starting up the .NET WebAssembly runtime, not the download. I believe the issue is we don't currently have a way to download the .NET WebAssembly runtime without also starting it, so this delay happens even on the first visit when using interactive server rendering. But even if we could avoid that delay on the first visit, on subsequent visits you'd still see the delay as the runtime starts up even though the runtime has been cached.

@lewing @MackinnonBuck

[carlfranklin]

I’m seeing the same thing

[ray440]

If you change the Counter title to:

<h1>Counter @(OperatingSystem.IsBrowser() ? "Wasm" : "Server")</h1>

It's kinda neat to watch the change as it happens.

The delay is expected but much longer than expected leading to a stalled UX for antsy users.

Is there a way to tell what @rendermode is?

[danroth27]

Is there a way to tell what @rendermode is?

Not currently: #49401

[carlfranklin]

Can we hook afterWebAssemblyStarted in JavaScript to determine when WASM is loaded ?

…

On Fri, Nov 17, 2023 at 3:24 PM Daniel Roth ***@***.***> wrote: Is there a way to tell what @rendermode is? Not currently: #49401 <#49401> — Reply to this email directly, view it on GitHub <#52154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALK4DEIYV3XZ563XNJ2ELDYE7BW7AVCNFSM6AAAAAA7P3ZQMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGA2TGNRVGU> . You are receiving this because you commented.Message ID: ***@***.***>

[mkalinski93]

I found out that OnAfterRender actually can be an indicator that the framework and dependencies has been loaded. I think I'm going to have a root level component that will display a waiting indicator or something. My problem is that my clients will have a fast initial response from the server, but the overall hydration is taking a long time (especially on mobile end with slow connectivity)

In the end, my clients would be more confused when there's no interactivity yet established. My observation is that OnAfterRender gets executed when the framework has been loaded fully. Maybe we can get used to it.

[SteveSandersonMS]

@carlfranklin I’m seeing the same thing

Can you clarify what same thing you are seeing? The original report suggested that the UI is locked while downloading WebAssembly resources, but as far as we understand that is not the case.

If you mean that the UI is locked while the WebAssembly runtime starts (not while downloading, but after downloading), this is true and always has been since the beginning of Blazor WebAssembly. Over the years we've made it faster - it took about 1 second to start on the first version, and is down to about 350ms on recent hardware. Of course it could take longer on a low-end mobile device.

Update: I think I get what you mean now, which is that on the first visit for a given user, when it's using Server interactivity
because WebAssembly files aren't yet downloaded, there is a small pause (usually< 500ms, but depends on CPU speed) once the WebAssembly files finish downloading. Is that right?

If you change the Counter title to: <h1>Counter @(OperatingSystem.IsBrowser() ? "Wasm" : "Server")</h1> It's kinda neat to watch the change as it happens.

The switchover you'll be seeing here is between prerendered content (which will display "Server") and then live interactive content (which will display "Wasm" if the wasm resources are already downloaded and cached). What sort of delay are you seeing that is much longer than expected?

[AmBplus]

@SteveSandersonMS (usually< 500ms, but depends on CPU speed)

It seems this problem only happens in debug mode. What I mean is that it's more noticeable, not that there is no locking at all in other modes.
In debug mode with Visual Studio it takes around 6 seconds , with dotnet run it takes less than 1 sec or half sec, and in release you almost don't feel your page is locked.
It seems like we don't have any issues in production mode.

[carlfranklin]

Thanks!

…

On Mon, Nov 20, 2023 at 11:27 AM Amir ***@***.***> wrote: @SteveSandersonMS <https://github.com/SteveSandersonMS> (usually< 500ms, but depends on CPU speed) It seems this problem only happens in debug mode. What I mean is that it's more noticeable, not that there is no locking at all in other modes. In debug mode with Visual Studio it takes around 6 seconds , with dotnet run it takes less than 1 sec or half sec, and in release you almost don't feel your page is locked. It seems like we don't have any issues in production mode. — Reply to this email directly, view it on GitHub <#52154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALK4DGFT5QET6HDQOZXO3LYFOAFVAVCNFSM6AAAAAA7P3ZQMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJZGM4TKMBYHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ziaulhasanhamim]

@SteveSandersonMS I am facing the same issue. In auto interactivity mode it is supposed to connect to the server with signalr instantly. But it doesn't do that rather it waits for the wasm runtime to be loaded and then connects to the server. It destroys the whole purpose of auto interactivity. The app doesn't become interactive before wasm runtime loads unlike server mode which starts instantaneously. In my case the browser first loads webassembly files and then it connects to the server with signalr. Shouldn't it first make a signalr connection and then load the files? In my network tab, I can clearly see that wasm files are downloaded before websocket connection.

[SteveSandersonMS]

In my case the browser first loads webassembly files and then it connects to the server with signalr

@ziaulhasanhamim When you use the word "loads" here, do you mean "downloads" (as in the WebAssembly files are not already cached, and you are waiting for them to be transferred over the network), or do you mean it in the sense of "starts" (as in, the WebAssembly files are already downloaded, but it takes some nonzero time to start the .NET runtime under WebAssembly, most likely ~0.5s assuming you are not debugging).

[ziaulhasanhamim]

@SteveSandersonMS I meant that it is not cached. When wasm runtime is not cached it first downloads the wasm files then connects to server through websockets. But if it has to download the wasm runtime first then what is the benefit of auto interactivity.

[AmBplus]

@ziaulhasanhamim , Try Publish And See Still Have Delay