Skip to content

Blazor WASM: certain startup errors don't trigger error pop-up in the UI #91276

Closed
@andreimilto

Description

@andreimilto

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

If an error happens when the Blazor WASM website is loading, the standard error pop-up should appear in the UI:
error

There are some cases when the error dialog doesn't show up and the page appears frozen in the loading process to the user:
no error

Test cases:

  1. File _framework/dotnet.wasm has invalid hash - error dialog pops up.
    1 - dotnet hash

  2. File _framework/dotnet.wasm is missing (error 404) - error dialog pops up.
    2 - dotnet 404

  3. File _framework/System.Collections.dll has invalid hash - no error dialog.
    3 - collections hash

  4. File _framework/System.Collections.dll is missing (error 404) - no error dialog.
    4 - collections 404

  5. File _framework/System.Collections.dll is missing (error 404) and BlazorCacheBootResources set to false - error dialog pops up.
    5 - collections 404 no cache

The following two test cases use custom logic in the loadBootResource to manually fetch .br files from the server, as suggested in the ASP.NET Core docs:

<script src="_framework/blazor.webassembly.js" autostart="false"></script>
<script type="module">
    import { BrotliDecode } from './decode.js';
    Blazor.start({
        loadBootResource: function (type, name, defaultUri, integrity) {
            if (type !== 'dotnetjs' && location.hostname !== 'localhost') {
                return (async function () {
                    const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
                    if (!response.ok) {
                        throw new Error(response.statusText);
                    }
                    const originalResponseBuffer = await response.arrayBuffer();
                    const originalResponseArray = new Int8Array(originalResponseBuffer);
                    const decompressedResponseArray = BrotliDecode(originalResponseArray);
                    const contentType = type ===
                        'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
                    return new Response(decompressedResponseArray,
                        { headers: { 'content-type': contentType } });
                })();
            }
        }
    });
</script>
  1. File _framework/dotnet.wasm.br is missing, custom loadBootResource - error dialog pops up.
    6 - dotnet br 404

  2. File _framework/System.Collections.dll.br is missing, custom loadBootResource - no error dialog.
    7 - collections br 404

Expected Behavior

Error dialog should appear in all of the above test cases. Currently it doesn't appear in the tests 3, 4 and 7.

Steps To Reproduce

In Visual Studio 2022 create a project using Blazor WebAssembly App template with the options:

  • Framework - .NET 7.0
  • Authentication type - None
  • Configure for HTTPS - No
  • ASP.NET Core Hosted - No
  • Progressive Web Application - No
  • Do not use top-level statements - Yes

Publish to folder, reproducing the conditions of the above tests.

Exceptions (if any)

No response

.NET Version

7.0.306

Anything else?

No response

Metadata

Metadata

Assignees

Labels

arch-wasmWebAssembly architectureneeds-area-labelAn area label is needed to ensure this gets routed to the appropriate area owners

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions