Ability to determine if current navigation is originating from canceledNavigationResolution=computed or skip the navigation altogether if oldUrl=newUrl #70784

Which @angular/* package(s) are relevant/related to the feature request?

router

Description

Use case is similar to the one described by #52924, but the issues goes further than router guards - there is no way (public, I see there is some internal route navigation generation/revision marker here

, perhaps that could be sufficient?), to determine if current navigation is the one the router triggers when it attempts to repopulate route history.

Example at:

https://stackblitz.com/edit/stackblitz-starters-d1cphwdg?file=src%2Fmain.ts

1. go to A
2. go to B
3. press browser back button
4. the canDeactivate guard will trigger
5. say no to the confirmation
6. router attemtps to restore original history - this triggers new navigation new navigation due to canceledNavigationResolution=computed, this is a navigation of "go to B" - current route page already is "B", this navigation then does get executed even though url at step 3, the final url and one of this navigation are the same, due to onSameUrlNavigation=reload.

Now weird semantics happen - the canDeactivate guard gets activated again (cause it has runGuardsAndResolvers=always), NavigationEnd fires on success, even though nothing has changed (or rather, navigation, which was not triggered by the user, to same url as the one they have attempted to leave, generated by canceledNavigationResolution=computed occured). I did not find any way to distinquish this activation from the regular navigation one.

One could tweak the runGuardsAndResolvers strategy such that it only runs eg.: on url change, but then there is no way to run the same guard even when its desired for a navigation that does not change URL and does not originate from canceledNavigationResolution=computed to activate it.

Proposed solution

Add a flag on router config or some other option to skip the router navigation that happens due to canceledNavigationResolution=computed, while retaining the behavior that updates the history.

Exclude onSameUrlNavigation=reload from being applied to the navigation stemming from canceledNavigationResolution=computed.

Alternatives considered

I see there is some internal route navigation generation/revision marker here

, perhaps that could be way to detect the navigation origin?