NavigationLock with ConfirmExternalNavigations doesn't show confirm dialog when changing address bar after initial app load

[danroth27]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Using NavigationLock with ConfirmExternalNavigations doesn't show confirm dialog when changing address bar after the initial app load.

Expected Behavior

Confirm dialog is shown after changing the address bar even on first load.

Steps To Reproduce

• Create a Blazor WebAssembly app
• Add <NavigationLock ConfirmExternalNavigations /> to Index.razor
• Run the app
• After the app loads, change the address bar to a different external address

Exceptions (if any)

None. Browser console looks clean.

.NET Version

7.0.100-rc.1.22429.3

Anything else?

If you navigate internally, like to the Counter page first and then back to Home, then changing the address bar does trigger the confirm dialog.

External links, like an anchor tag pointing to blazor.net on the home page, also successfully get interrupted.

Repros with both Edge and Chrome.

[javiercn]

I think this is by design. We can't intercept anything when the user changes the page on the address bar. Otherwise, you would be able to trap users in a page. But I'll let @MackinnonBuck add his thoughts.

[danroth27]

I think this is by design. We can't intercept anything when the user changes the page on the address bar. Otherwise, you would be able to trap users in a page. But I'll let @MackinnonBuck add his thoughts.

If you navigate internally, like to the Counter page first and then back to Home, then changing the address bar does trigger the confirm dialog. It's only after first load that changing the address bar doesn't seem to trigger the prompt.

[javiercn]

@danroth27 do you mean changing the address in the address bar?

[MackinnonBuck]

It is a bit strange that changing the address bar is the only thing that doesn't cause the prompt to display, and only if it's the first "navigation" that occurs. It could be that browsers require some sort of user interaction in the page before the beforeunload event is allowed to fire. Regardless, this is definitely something worth investigating so we know exactly what's going on.

[MackinnonBuck]

Looks like it's true that browsers require user interaction on a page before the beforeunload event can fire. I was able to reproduce this behavior, but if I did as little as highlight some text on the page before changing the URL in the address bar, the prompt displayed correctly.

Closing this as by-design.