[Blazor] NavigationLock LocationChangingContext CancellationToken cancelled every time navigation location changes

[pantoast]

Describe the bug

I am attempting to react to navigation being canceled. I have a NavigationLock component in my razor and am handling its OnBeforeInternalNavigation event. That event has 1 parameter of type LocationChangingContext which has a CancellationToken property. When I register a delegate to be called when that CancellationToken is cancelled, I find that it fires the delegate every time the location is changed - regardless of whether it was actually cancelled or not.

Expected Behavior

LocationChangingContext's CancellationToken only calls registered delegates when the navigation is cancelled, not on successful navigation.

Steps To Reproduce

https://github.com/pantoast/NavigationLockCancellationTokenDelegateDemo

.NET Version

7.0.101

Anything else?

Microsoft Visual Studio Enterprise 2022 (64-bit) Version 17.4.3

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 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.

[MackinnonBuck]

Thanks for reaching out, @pantoast.

I believe the reasoning behind the current implementation was that any pending work relating to the change of the location should be canceled when the navigation completes (either by continuing or being prevented). However, I appreciate that this can be somewhat unintuitive, and it contradicts what the XML docs for LocationChangingContext.CancellationToken indicate the behavior should be, so this seems like something we should consider changing.

[pantoast]

Thanks for the response. I see what you mean regarding using it to cancel pending work.

Since this change may not make it in until .NET 8 if ever, is there currently a way to react to navigation being cancelled by a child component?

My code performs work when the location is changing. However, because the OnBeforeInternalNavigation event is fired top-down, if a child component cancels navigation then I would like to undo the work done by the parent component. This cancellation token was the only thing I found built in and obviously it doesn't work the way I expected it to.

[MackinnonBuck]

@pantoast One way is to have the parent component manage its own CancellationTokenSource that child components can utilize to cancel work that the parent is doing. Using CascadingValue, the parent component passes itself (this) to child components. Any child component receiving the cascading parameter can then invoke a method on the parent component that cancels the CancellationTokenSource, thus undoing whatever work the parent did or is currently doing.

Or, if you're directly rendering a single child component that you know is the only one capable of cancelling navigations, you could directly pass it an EventCallback that does the cancellation.

Any flavor of that general strategy tailored to how your code is structured should work.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 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.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.