NavigationManager.NavigateTo doesn't navigate in Blazor Web App

[danroth27]

Repro steps:

• Create a Blazor Web App with server interactivity enabled
• Update Index.razor with:

@page "/"
@inject NavigationManager NavigationManager
@attribute [RenderModeServer]
<PageTitle>Index</PageTitle>

<h1>Hello, world!</h1>

Welcome to your new app.

<button @onclick="Navigate">Navigate</button>

@code {
    void Navigate()
    {
        Console.WriteLine("Navigate");
        NavigationManager.NavigateTo("/counter");
    }
}

• Run the app and click the Navigate button

Expected result: App navigates to the Counter
Actual result: Browser address updates, but the counter isn't rendered:

[SteveSandersonMS]

Good report. What's happening is that because the source page is interactive but has no interactive router,

• Your .NET code issues a programmatic navigation, which results in a call to JS telling to navigate
• The JS code begins the navigation flow by updating the URL
• Next it sees that you're navigating to an internal URL, so it doesn't try to leave the page, but instead issues a call into .NET to raise the OnLocationChanged/OnLocationChanging events
• Normally those events would be received by a <Router> which would match against its route table, and if there's no match, would trigger a full-page load to the destination URL
• However in this case you have no <Router> so the OnLocationChanged/OnLocationChanging events are just ignored

It's slightly awkward because in theory, the developer might have some custom code that listens to OnLocationChanged/OnLocationChanging to perform arbitrary actions in this case, so we don't know for sure that any of this flow is actually wrong. Maybe you wanted to take no action on these events!

I think the best resolution here will be for us to add an extra condition that the JS-side code only attempts to notify .NET (and to cause OnLocationChanged/OnLocationChanging) when navigation interception has been enabled, which is something that <Router> does. The JS side navigation code already varies its behavior in quite a few ways based on whether there's a navigation interceptor, i.e., an interactive router.

At first I thought this could as breaking change as now you'd only be able to use OnLocationChanged/OnLocationChanging if you have either a <Router> or a custom router that uses enableNavigationInterception. However OnLocationChanged/OnLocationChanging already only react to navigation clicks and popstate if you use enableNavigationInterception, so the only case that would change is NavigationManager.NavigateTo, and it's hard to see a legit reason why that should differ from link clicks and back/forward. As such I think it's better regarded as a bugfix.