New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
intercepting same-document navigation caused by a user' direct address input in browser address bar#10258
Comments
I think I had missed something before posting this issue: The spec explicitly says the I totally understand firing a But it's not necessary to cut it all, I think it's reasonable to fire a |
This faithfulness to user intent is an important part of the user-facing security model. Stepping back, I don't really understand your use case. In what scenarios are users hacking on non-fragment parts of the URL in their URL bar (already very rare), and somehow they expect this not to cause a page load? You mention something about someone sharing a URL. Usually when one shares a URL to someone else, it's via something like a chat application. Clicking a link from a chat application into a web browser will always cause a full page load, as part of loading the browser. I don't understand what this has to do with modifying the contents of the URL bar. |
Consider if I am working on a multi-task page:
And then someone shares a page:
I copy-paste and go to the shared page by the location bar, and then I see:
This gives advantages over a complete page load:
Putting aside the "what will we benefit for firing This is my perspective, and I welcome any opinions from everyone. |
The benefit is the user-facing security model. Users know that when they change the non-fragment portion of a URL, they are going to do a new page load. Doing a new page load is important for users in various ways, from escaping abusive pages, to freeing up memory. Violating this user expectation is not something we're currently interested in doing in Chrome without a compelling reason. The example use case you've provided is not very compelling: it seems extremely rare, and the advantages you list are very small. |
In Chrome,
navigate
event listeners cannot intercept same-document navigation which is caused by a user' direct address input in browser address bar.I read the spec and was unable to find any explicit statement made clear that a user' direct address input can be intercepted in a
navigate
event listener.I think intercepting direct address input in the same document is a necessary feature for making a SPA look completely like a SPA. It's especially useful for a heavy-sharing SPA where someone shares some URL to others frequently.
The text was updated successfully, but these errors were encountered: