[Blazor] Add support for confirming navigations

[pranavkm]

Summary

Support for Location change event is a very popular ask from our users. Unfortunately, given the nature of the event adding support for it that uses browser intrinsic is going to be difficult / impossible. #24417 attempted to solve this by hijacking browser navigation and managing it via Blazor. This is a fairly involved solution, with possible significant perf overhead, and we'd like to determine if using a narrower solution would suffice here.

A popular theme in the issue focused on preventing navigation to avoid losing unsaved changes in a component. A well-upvoted comment provides a sample for just this - https://github.com/ShaunCurtis/Blazr.Demo.EditForm/tree/master/Blazr.NavigationLocker. This spec is a way to determine if this is something we could get away with.

Motivation and goals

• Most popular issue for Blazor at the time of writing.

In-scope

• Add an API that allows components to prevent navigation in a platform-independent way.
• Provide turnkey solution that integrates with EditForm

Out-of-scope

• Not a general purpose location changing event handler.

Proposed solution

We introduce an API on NavigationManager that allows users to confirm when a navigation is to occur.AddNavigationConfirmationAsync returns an IAsyncDisposable which prompts for a confirmation until the returned value is disposed.

public class NavigationManager
{
+   public ValueTask<IAsyncDisposable> AddNavigationConfirmationAsync(string message, CancellationToken cancellationToken);
}

Here's an example of it in use:

@inject NavigationManager Nav

<form @oninput="OnInput" @onvalidsubmit="OnSubmit">
    ...
    <button type="submit">Submit</button>
</form>

@code {
    IAsyncDisposable? _navigationConfirmation;

    async Task OnInput()
    {
        _navigationConfirmation ??= await Nav.AddNavigationConfirmationAsync("Are you sure you want to exit without saving?");
    }
    
    async Task OnSubmit() => await RemoveNavigationConfirmationAsync();

    ValueTask IAsyncDisposable.DisposeAsync() => RemoveNavigationConfirmationAsync();
    
    ValueTask ClearConfirmationAsync() => await (_navigationConfirmation?.DisposeAsync() ?? default);
}

The implementation relies on window.confirm for a navigation that is handled via Blazor's routing and beforeunload event for all other navigation. The message parameter is used as part of the confirm dialog, but is likely to be ignored by the unload event since browsers do not consistently support specifying it.

In addition to this, we introduce a LockNavigationWhenDirty component that uses EditContext's dirty state (IsModified() / MarkAsUnmodified()`) to add / remove navigation confirmations. Here is what this component looks like:

public class LockNavigationWhenDirty : IAsyncDisposable
{
    public LockNavigationWhenDirty(NavigationManager navigationManager);
    [EditorRequired, Parameter] public string Message { get; set; }
}

Usage:

<EditForm ... @onvalidsubmit="OnValidSubmit">
    <LockNavigationWhenDirty /> 
    ...
</EditForm>

@code {
    async OnValidSubmit()
    {
        // Save content
        repository.SaveAsync(..);
        
        // Release the lock now that we're satisfied
        editContext.MarkAsUnmodified();
    }
}

[DaveNay]

Can the use of window.confirm be replaced with a generic callback that can be handled in user code? The browser dialogs are pretty ugly and do not fit with custom site theming.

[pranavkm]

@DaveNay that seems like a reasonable ask. I think we should be able to support a callback for anchor tags / if the navigation is handled by Blazor's routing.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[alxtr3]

not already supporting onlocationchanging and cancel of navigation is just crazy!

also LocationChanged doesn't work when loading a page outside the current blazor app and Dispose() methods on the razor components are not even called when exiting the app.. hahaha I'm sure you will add this to .Net 10 planning haha

[robertmclaws]

I guess for me, I just never really understood why it was such a performance issue. If you can plug into the browser navigation system enough to cancel a navigation, then why wouldn't you:

• Have the NavigationManager track that a Navigation happened
• Cancel the browser navigation event
• Let the NavigationManager await a NavigationChanging event
• Re-issue the Navigation event if the value from the NavigationChanging func is true (the return value meaning OK to navigate)

What about that is a performance problem?

[ShaunCurtis]

I can't say that I'm happy with this. There's no control for the programmer, just another popup box that we have little control over. I want to stop Navigation in a dirty form, and potentially show an in-form alert or toast. A simple bool BlockNavigation flag to turn off navigation, and a NavigationBlocked event to capture blocked navigation attempts. I can guess that's not going to fly because programmers could just turn off routing without realising it!

If the changed proposed above was implemented, I don't think I would use it in the majority of circumstances, just as I don't use the EditContext IsDirty because it's far too simplistic: for example, I can change a value back to it's original and the EditContext is still dirty though the underlying data object isn't.

Can we not do something with the Server JS interop call so we can plug in another Navigation Manager, as we can do with WASM? I'm guessing it wasn't designed that way, but... I'll have a think about that.

[robertmclaws]

If the changed proposed above was implemented, I don't think I would use it in the majority of circumstances, just as I don't use the EditContext IsDirty because it's far too simplistic: for example, I can change a value back to it's original and the EditContext is still dirty though the underlying data object isn't.

100% agree with this. We implemented INotifyPropertyChanged, IChangeTracking, and IRevertibleChangeTracking in our objects instead and eliminated our dependence on EditContext for this very reason.

Baking in a window.confirm means I will have virtually zero control over the branding and design of what happens in these situations. That isn't terribly useful, IMO.

If I can build a router using crossroads + history in javascript to handle this (which was based off the ASP.NET Core Knockout SPA template, BTW) then this problem can be solved in Blazor too.

[MariovanZeist]

Like other commenters here I would advise against using window.confirm to show a simple browser-specific dialog that cannot be styled and is limited in functionality. I think it will confuse the user as the confirmation dialog would stand out, and users might even believe that it's not part of the current application they are using.

I would also caution to use the beforeunload event in conjunction with window.confirm As stated in that paragraph:

To combat unwanted pop-ups, browsers may not display prompts created in beforeunload event handlers unless the page has been interacted with, or may even not display them at all.

(This was also the reason this event wasn't used in the above-mentioned PR, as its implementation and usefulness varied amongst browsers)

Although this proposal initially seems simpler than #24417 I would argue the complexity will approach that of the PR, as you still want to be able to cancel navigation in all the below cases:

1. Calling NavigationManager.NavigateTo directly (except when setting the forceload flag),
2. Clicking an href element
3. Performing a history.back or history.forward function or clicking the back / forward history buttons in the browser.

And without using onbeforeunload I would assume that at a minimum, the same events will have to be intercepted
I admit with this proposal the handling of those events would be simplified as I suspect the envisioned proposed solution would only have to check a variable and when it's set it would display the window.confirm dialog with a predetermined message and abort the navigation when the user presses cancel.

This proposal would also get rid of the additional Browser -> Server interaction (only when using Blazor Server, and which in the original PR would only be incurred when the developer had actually implemented an EventHandler) but at a high cost of losing all the flexibility and customizability that having a LocationChanging event in C# would bring.

And personally, the performance impact of that additional Browser -> Server interaction in that PR is negligible, as it will

1. Only happen when the developer actually monitors for location changes.
2. The user actually does an action that performs navigation.

As the original author of #24417 I admit I might be biased towards a similar solution, And although @pranavkm explicitly stated that this was out-of-scope, maybe we could build upon it while addressing some of the criticism. I would love to take another crack at this problem.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.