Navigation event for address change by user

WICG / navigation-api

The new navigation API provides a new interface for navigations and session history, with a focus on single-page application navigations.

https://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-api

484 stars 30 forks source link

Navigation event for address change by user #245

Open jjkola-eskosystems opened 2 years ago

jjkola-eskosystems commented 2 years ago

I would like to see navigation event generated for the case when user changes the address of the tab/window. Based on my testing on Chrome it seems that if the user changes/adds only the fragment then the navigation event will be issued but if it is completely different page (or fragment is removed) then no event is fired even if the new page is on the same origin.

To prevent misuse of the event I would like to see following rules applied:

to prevent abuse of forcing user to remain on the current page allow canceling/intercepting only once in the same way as back/forward functionality
in the case the new address conforms to same origin, the new address is supplied in the event
in the case the new address does not conform to same origin, the new address is not supplied in the event

There is also the case of user supplying address which causes browser to download content (and may or may not return to original document).

Any thoughts on the issue?

domenic commented 2 years ago

Let me clarify what you're asking for:

Are you asking just to observe the user navigating away from your document? This is possible already using the unload and beforeunload events.
Are you asking to be able to prevent the user from navigating away from your document? This is possible already using the beforeunload event, with certain restrictions (including a user prompt, which is necessary to prevent abuse).
Are you asking to be able to prevent the user from navigating away from your document, and instead cause a same-document navigation to the user's target URL (if same-origin)? This is possible already by combining the beforeunload event (with the aforementioned restrictions) plus the navigation API or the classic history API.

In all cases, I guess the missing piece of information is where the user is going. So we could consider adding that information, if it's same-origin, to the unload and beforeunload events. (However, this would need some discussion; merely the fact that the user is leaving to a same- vs. cross-origin page might be considered sensitive, as it's basically allowing you to track user activity.)

jjkola-eskosystems commented 2 years ago

Unfortunately unload and beforeunload methods are not reliable to track when the user leaves the site (this is the reason I have had to make a library which tracks user actions, mostly window close and address changes). Also, they may change how browser behaves with the current page.

About preventing the user navigating away from the document I just thought that it would be better if it behaved in the same way as other navigation API interactions (namely you could prevent navigation or intercept the navigation when reasonable).

For the library I have done I'm not interested in where the user is going I'm only interested when the user leaves the page (either by navigating away (programmatically or by user action) or by closing the window). But I thought that it would be better to specify how the API should behave when the user inputted address is not of the same-origin.

domenic commented 2 years ago

Please say more about why the existing methods are not reliable. Adding a new API is not the usual way to fix bugs in an old API.

But I thought that it would be better to specify how the API should behave when the user inputted address is not of the same-origin.

It is specified. No events fire.

jjkola-eskosystems commented 2 years ago

With IE the unload and beforeunload event would always fire (thus would be 100% reliable) but at least for the Chrome and Edge the event would fire only if the browser would detect enough interaction with the page. This is problem for us as we are closing opened windows in those events and it needs to be reliable (we develop patient care software (multiple SPAs) and users must not mix patients). Our solution to issue was to develop a library which tracks open windows (by having separate window which opens the window) and ensures they are closed when the parent window closes.

To detect when the library is in use we have added detection for address changes and as navigation API provided easy way to detect this we have started using it. It is mostly reliable but unfortunately there is some corner cases where navigation API does not fire events at all, or fires "navigation" event but no subsequent "navigationsuccess" or "navigationerror" event even though it returns to same document. The latter case happens at least in the cases of download links. Download case was fixed by adding timeout callback but would love to see this fixed by getting a reliable event.

domenic commented 2 years ago

Ah, yeah. If a page is not interacted with, we will never give it any chance to observe or trap the user's activity. Sorry, that is not negotiable; we will not add some new event that lets you do that.

jjkola-eskosystems commented 2 years ago

In this case the page was interacted with by opening other windows and scrolling but unfortunately browser did not deem this as enough interaction. And that's the problem as we can't influence what is deemed as interacting with the page. To work around this issue it would be nice if there was separate way to affect this by either deeming what is seen as interaction or allowing to disable the interaction check case by case (either by origin or even by address). If there was such feature then we wouldn't need the library at all.

jjkola-eskosystems commented 2 years ago

Also, what is seen as user interaction. We have had cases where the action was initiated by the user and then we needed to call server API and based on the reply do things but if the fetch took too long then opening a new window was deemed not as user action and was blocked. This caused some hard to find out errors as this was not seen if the server replied quick enough. This is because many of the users are not tech savvy and didn't notice the block icon. Only when this issue was brought open during the library development did we realize that it was caused by this.

jespertheend commented 1 year ago

I'm hosting a game with a url like http://localhost:8080/?level=1. Now I'd like the user to be able to change the level by changing the url in the address bar without the page reloading, similar to what would be possible with a hash in the url.

beforeunload doesn't work here because of the prompt. The prompt makes sense to prevent abuse, but can it still be abused when the user is only navigating to a page with the same the origin?