NavigationLock not working with enhanced navigation in an interactive server page component

[marinasundstrom]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

NavigationLock doesn't activate when navigation away using link that triggers enhanced navigation in an interactive server page component. (For instance a link in the navbar)

Only works on page refresh.

Expected Behavior

The OnBeforeInternalNavigation should be triggered on enhanced navigation to another page.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

8.0.100-rc.2.23502.2

Anything else?

No response

Hi @marinasundstrom. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[MackinnonBuck]

Thanks for reporting this, @marinasundstrom. To clarify, is the scenario that you have an interactive component on the page trying to block enhanced navigation? Or does your scenario only involve statically-rendered components?

[marinasundstrom]

@MackinnonBuck Ah. Forgot. It's when I'm on a page which is an interactive server component.

It doesn't block enhanced navigations. The only time the handler is being called is when doing a hard navigation, like a refresh.

[MackinnonBuck]

It doesn't block enhanced navigations.

This is expected and by-design (since there is no interactive router), but I can see how this might not be intuitive.

We did just make a change recently that makes enhanced navigations invoke the LocationChanged event, though. I wonder if it would be worth extending this to also invoke location changing handlers and allow for the cancellation of enhanced navigations. This would be theoretically possible, but opens up some other questions too. For example, if an interactive runtime initiates a programmatic navigation using NavigationManager.NavigateTo(), should location changing handlers be invoked in all other interactive runtimes? If so, this would require updating the implementation to perform multiple extra .NET<-->JS interop calls to coordinate the cancellation of the navigation.

The only time the handler is being called is when doing a hard navigation, like a refresh.

I'm surprised that the location changing handler runs at all in this case. Or are you referring to the ConfirmExternalNavigation parameter on NavigationLock? That actually uses the beforeunload event to prompt the user and doesn't rely on registering a location changing handler.

Here's the behavior of navigation events when using server-side routing today (assuming internal navigations if possible):

Navigation type	Location changed	Location changing	Explanation/justification
NavigationManager.NavigateTo() (interactive)	✅	✅1	Navigation is completely controlled by the interactive runtime
NavigationManager.Refresh() (interactive)	✅	❌	Causes an enhanced navigation, so is consistent with other enhanced navigation triggers
Browser link click	✅	❌	Causes an enhanced navigation, so is consistent with other enhanced navigation triggers
NavigationManager.NavigateTo() (SSR)	❌	❌	Navigations during SSR are treated as redirects and don't go through the normal Blazor navigation code path
NavigationManager.Refresh(forceReload: true) (interactive)	❌	❌	Consistent with clicking the "refresh" button on the browser

And here's the behavior when using client-side routing:

Navigation type	Location changed	Location changing	Explanation/justification
NavigationManager.NavigateTo() (interactive)	✅	✅	Navigation is completely controlled by the interactive runtime
NavigationManager.Refresh() (interactive)	❌	❌	Enhanced navigation cannot be performed, so this is treated the same as NavigationManager.Refresh(forceReload: true)
Browser link click	✅	✅	Navigation is handled by the interactive router
NavigationManager.NavigateTo() (SSR)	❌	❌	Navigations during SSR are treated as redirects and don't go through the normal Blazor navigation code path
NavigationManager.Refresh(forceReload: true) (interactive)	❌	❌	Consistent with clicking the "refresh" button on the browser

I think the things here that are candidates for reconsideration are:

• Enhanced navigations invoke location changing handlers in all interactive runtimes
  • If we did this, we would need to think about whether NavigationManager.NavigateTo() should also allow other interactive runtimes to cancel the navigation
• To be consistent with location changing handlers not being invoked for enhanced navigations, NavigationManager.NavigateTo() also does not invoke location changing handlers if there is no client-side router

I think if we were going to make one of the two above changes, we should make the second one. This would turn ✅¹ into an ❌.
That way, the rules are super clear and predictable:

• When interactive routing is used, location changing handlers always get invoked for internal navigations
• When server-side routing is used, location changing handlers are never invoked

What you think? @marinasundstrom @danroth27 @javiercn @SteveSandersonMS

[SteveSandersonMS]

@MackinnonBuck Your proposal sounds good to me. I agree it makes the rules simpler. However I've no idea if it would meet the bar for something we'd do before GA, or even if we could plan to bring this as an obscure breaking change into an 8.0.x servicing release based on the idea that we're denoting it as a bug. @mkArtakMSFT

[marinasundstrom]

@MackinnonBuck Yes, it was the ConfirmExternalNavigation that was executed. But the in app navigating didn't trigger. Which is an odd behavior for an interactive page, at least.