Feature: Add more information about the source of abort signal (and navigateerror)

[atscott]

Neither the navigateerror event nor the reason for abort on the abort signal provide information about why a navigation was aborted. There are many different reasons for this (user clicked the x button or escape key, a new navigation started, or a handler promise rejected) and routers may want to take different actions for each one.

Aside from the case where a navigation was canceled by a new navigation, “rolling back” the navigation by traversing to the previous entry is likely desirable, especially if the previous page is still displayed (It’d be a bit odd to display the previous page but the url is for the aborted navigation).

The only current way I can think of to tell if a navigation is aborted by a new navigation event is to wait a macrotask and check to see if a new event was observed during that period.

[dmail]

The only current way I can think of to tell if a navigation is aborted by a new navigation event is to wait a macrotask and check to see if a new event was observed during that period.

That's what I use and it feels dirty.

On my side I want to know when user clicks browser x button to cancel every pending tasks. When there is an other navigation I cancel selectively, not necessarily everything