[Validation] Navigating between pages that use different render modes

[oroztocil]

Scenario contact: @javiercn

Scenario

Blazor writes bookkeeping into the page as HTML comments: WebAssembly options, persisted component state, JavaScript initializers. In .NET 10 those comments were pulled into Blazor's logical tree during the first render, then removed from the DOM during component discovery, leaving the tree pointing at nodes that no longer existed. The next enhanced navigation across a render-mode boundary hit one of those dangling references and threw Cannot read properties of null (reading 'insertBefore'): the address bar changed, no new page appeared, and only a full reload or forceLoad: true recovered.

This is a .NET 10 regression. The <!--Blazor-WebAssembly:...--> comment arrived in .NET 10 with WebAssembly options discovery, and nothing filtered it out of the tree. .NET 11 skips metadata comments when the logical tree is built. Two separate customer reports drove the fix, and this scenario reproduces both: navigating from a WebAssembly page to an Interactive Server page, and navigating away from a page that sets no <PageTitle>.

Minimum build

.NET 11 Preview 7 or later.

Configurations to cover

• Blazor Web App
  • Static SSR
  • Interactive Server
  • Interactive WebAssembly
  • Interactive Auto
• Standalone WebAssembly
• Hybrid (MAUI)

This is one app containing all three modes, not three runs. The ticks say which page render modes the app needs, because the bug only appears when navigating from one mode to another.

The app must be WebAssembly-capable, since that is what emits the Blazor-WebAssembly comment the regression was about. Create it with -int Auto or -int WebAssembly and then set the mode per page. Interactive Auto is left unticked as a page mode: an Auto page is Server on the first visit and WebAssembly afterwards, so it exercises the same two paths the other pages already cover.

Also exercise

• Published output
• An existing .NET 10 app upgraded to .NET 11
• Trimming or ahead-of-time compilation
• More than one server instance, or a proxy in front
• Hot Reload
• An IDE as well as the command line
• Container

Published output is included because the Blazor-WebAssembly comment carries the fingerprinted resource collection, so its contents differ from a development build.

What to build

Create the app with dotnet new blazor -int Auto, leaving interactivity per page rather than global. The two reported repros need a specific arrangement, so follow this table exactly:

Route	Render mode	Project	<PageTitle>
/	@rendermode InteractiveWebAssembly	.Client	yes
/counter	@rendermode InteractiveWebAssembly	.Client	none
/weather	@rendermode InteractiveServer	server	yes
/about	none, so it is statically rendered	server	none

Two details in that table are load-bearing and easy to undo by accident:

• /counter and /about must have no <PageTitle> at all. Adding one is the documented workaround for the reported bug, so a page that has it cannot reproduce anything. You can tell these pages apart in the browser because the tab shows the address instead of a name.
• The home page at / must live in the .Client project and render on WebAssembly. The report that started this was written against exactly that arrangement.

Put a link to each page in the nav menu. Navigation has to happen by clicking links, because a typed address is a full page load and does not go through the code being fixed.

The metadata comments are what the fix is about, so make sure the page emits them. Add a component using [PersistentState] and a JavaScript initializer. Before testing, view the page source and confirm you can find comments beginning with:

<!--Blazor-WebAssembly:
<!--Blazor-Web-Initializers:
<!--Blazor-Server-Component-State:
<!--Blazor-WebAssembly-Component-State:

Those four are the ones this setup produces. The fix also filters <!--Blazor-Configuration:, which appears only if the app sets browser options, so add a <ConfigureBrowser> to the page if you want that one covered too.

If none of these appear, the app is not set up to reproduce the bug and a pass means nothing.

Things to try

Open the browser console and leave it open. Then, clicking nav links rather than typing addresses:

• / to /weather, WebAssembly to Interactive Server. This is the first reported repro.
• /counter to /, WebAssembly to WebAssembly, having first landed on /counter, which has no title. This is the second reported repro.
• /counter to /about, WebAssembly to static.
• The remaining ordered pairs between the four pages.
• The same navigations using browser back and forward.
• Typing a destination address directly, which worked in .NET 10 even when clicking the link did not. This separates enhanced navigation from a full page load.
• The same app on .NET 10, to see both failures this fixes.

Expected behavior

Every navigation renders the destination page, whatever render modes the two pages use and whether or not either page sets a title.

Must hold

• Navigating from / to /weather by clicking the nav link renders the weather page.
• Navigating from /counter to /, and from /counter to /about, renders the destination page. Visiting a page with no <PageTitle> does not break navigation from that point on.
• No Cannot read properties of null (reading 'insertBefore') error appears in the browser console during any navigation, nor any other error.
• Every ordered pair of the four pages navigates successfully, in both directions, and the address bar and the visible content agree.
• On pages that set a <PageTitle>, the document title changes to it. On /counter and /about the tab shows the address instead, which is expected and is not the failure being tested.
• A page reached by clicking a nav link becomes interactive, the same as when it is loaded directly by typing its address.
• No navigation needs a reload or forceLoad: true to recover.
• Going around all four pages five times without reloading ends with the app still working and the console still clean.

Expected differences between configurations

• The first visit to /server-page waits for a circuit and the first visit to /wasm-page waits for the runtime, so both are slower than a static page. Slower is expected; a page that does not render is a finding.

Evidence to capture

For any navigation that failed, the full browser console output including the stack trace, plus the page source of the page you navigated away from, since that is where the metadata comments live. Note whether the page you left had a <PageTitle>.

Documentation to use

• ASP.NET Core Blazor render modes
• Enhanced navigation and form handling

What to report

Report results using the format described in the validation testing manual. Include link to a repository with the test app.

[MihuBot]

I'm a bot. Here are possible related and/or duplicate issues (I may be wrong):

• .NET 10 Blazor navigation from wasm to interactive server broken #64472
• Blazor Web App Crash in .NET 10 When Auto Component on the Homepage #64722
• .Net 10 Blazor Enhanced Navigation in WASM fails due to no PageTitle #64522

[surya3655]

Validation Report

This report covers the evidence collected for navigating between pages that use different Blazor render modes. Results are evaluated against the failure criteria in this issue.

Environment

Field	Value
SDK/runtime	.NET 11.0.0-preview.7.26381.103
Browsers	Chrome and Microsoft Edge
Run modes represented below	Debug and published Release
Required minimum build	.NET 11 Preview 7 or later

Sample Link: blazor-render-mode-navigation-validation

Core Results

Scenario	Test Case	Action	Debug Evidence	Debug	Published Evidence	Published
S1	TC-S1-01	/ -> /weather	View	Fail	View	Fail
S2	TC-S2-01	/counter -> /	View	Pass	View	Pass
S3	TC-S3-01	/counter -> /about	View	Pass	View	Pass
S4	TC-S4-01	/ -> /counter	View	Pass	View	Pass
S4	TC-S4-03	/ -> /about	View	Pass	View	Pass
S4	TC-S4-05	/counter -> /weather	Same as issue TC-S1-01	Fail	Same as issue TC-S1-01	Fail
S4	TC-S4-07	/weather -> /	View	Pass	View	Pass
S4	TC-S4-08	/weather -> /counter	View	Pass	View	Pass
S4	TC-S4-09	/weather -> /about	View	Pass	View	Pass
S4	TC-S4-10	/about -> /	View	Pass	View	Pass
S4	TC-S4-11	/about -> /counter	View	Pass	View	Pass
S4	TC-S4-12	/about -> /weather	View	Pass	View	Pass
S5	TC-S5-01	/ -> /weather -> Back	View	Pass	View	Pass
S5	TC-S5-02	Back test -> Forward	View	Pass	View	Pass
S6	TC-S6-01	Type /weather	View	Pass	View	Pass
S6	TC-S6-02	Type /counter	View	Pass	View	Pass
S6	TC-S6-03	Type /about	View	Pass	View	Pass
S7	TC-S7-01	Navigate all routes five times	Video	Pass	Video	Pass

An existing .NET 10 app upgraded to .NET 11

This scenario validates cloning an existing available Blazor .NET 10 sample and upgrading it to .NET 11.

Evidence video: existing10-upgrade-to-11

Result: Pass

Steps followed:

1. Cloned the existing available Blazor .NET 10 sample.
2. Updated the project target framework from .NET 10 to .NET 11.
3. Restored and built the upgraded solution.
4. Ran the upgraded .NET 11 app.
5. Re-tested the render-mode navigation scenarios.

Notes:

• The upgraded app successfully ran on .NET 11.
• Navigation completed successfully except for the already documented Weather page flicker behavior.

Failure: S1-TC01-home-to-weather

Observed: When navigating to /weather, the page briefly shows Loading... before the weather table renders, causing visible flicker.

Configuration: App uses Interactive Auto. Weather page uses @rendermode InteractiveServer.

Expected: Navigation should render smoothly without visible flicker.

Failure condition:
The flicker occurs when navigating to the /weather page from any other page in the sample.

Affected navigation paths:

• / → /weather
• /counter → /weather
• /about → /weather

The issue is not observed when the explicit @rendermode InteractiveServer is removed from the Weather page.