Quick URL changes do not create history entries |
||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.109 Safari/537.36
Steps to reproduce the problem:
1. Go to a new tab.
2. Navigate the new tab to -
data:text/html,<!doctype html><script>window.location.hash = "3333"; setTimeout(() => { window.history.back(); }, 3000);</script>
What is the expected behavior?
The URL will be of the data URL, without any hash -
data:text/html,<!doctype html><script>window.location.hash = "3333"; setTimeout(() => { window.history.back(); window.kl(); }, 1000);</script>
What went wrong?
The URL will be the URL of the new tab (well, empty), or whatever page the tab was at before you navigated it to the data URL.
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 59.0.3071.109 Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
,
Jun 27 2017
Looks like quick URL changes do not create history entries at all.
data:text/html,<!doctype html><script>window.location.hash = "3333"; window.location.hash = "4444"; window.location.hash = "5555"; setTimeout(() => { window.history.back(); }, 3000);</script>
This still goes back to a document before the data URL.
However, delaying every URL change with a setTimeout of 500 milliseconds works properly -
data:text/html,<!doctype html><script>setTimeout(function () { window.location.hash = "3333"; setTimeout(function () { window.location.hash = "4444"; setTimeout(function () { window.location.hash = "5555"; setTimeout(() => { window.history.back(); }, 3000)}, 500); }, 500); }, 500);</script>
Probably WebKit issue/feature, reproduced in Safari 10.1 as well using BrowserStack.
,
Jun 27 2017
,
Jun 27 2017
japhet@: This sounds like it might be intentional, where the navigation is getting classified as a client redirect and then not creating a new history item. Is that right? Is that something where we expect to differ from other browsers?
,
Jun 27 2017
Since there are web-observable side effects to this, I think this should work the same across browsers. I mean, I am not arguing that the user-visible history list should have entries for those navigations, I am only arguing that the web-developer-visible history functionality (window.history APIs) should take those entries into account, even if the user cannot navigate to them using the user interface of the browser.
,
Jul 4 2017
loading triage: change the status to assigned as this was assigned to Nate.
,
Jul 18 2017
Safari, chromium, and edge all have the same behavior, so it looks like firefox is the odd one out. See https://html.spec.whatwg.org/#location-object-setter-navigate for the relevant chunk of the spec. I think our behavior, while probably not 100% spec compliant as relates to click event handling, is correct in this case, as the Document is not completely loaded. Feel free to reopen if I've missed something.
,
Jul 19 2017
#7 - can you file a specification bug, then, so Chrome would be specification-compliant?
,
Jul 19 2017
Sorry, I conflated two things in Comment #7. I think we're 100% correct in this specific case. I'm just not sure we follow https://html.spec.whatwg.org/#location-object-setter-navigate in all situations, as the special cases for click event handling are relatively new, I think. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by phistuck@chromium.org
, Jun 27 2017Oops, a correct answer for "What is the expected behavior?" is - The URL will be of the data URL, without the hash - data:text/html,<!doctype html><script>window.location.hash = "3333"; setTimeout(() => { window.history.back(); }, 3000);</script> Firefox gets this right.