[whatwg] JS "redirects" and session history

[Mihai Parparita]

I'm investigating a WebKit bug that occurs when navigating to hp.com
and then pressing the back button. The full details are at
https://webkit.org/b/42861, but briefly: onload hp.com sets
window.location.hash to #Product. In Firefox, IE, and Chrome, this
does not create a new session history entry (i.e. pressing the back
button goes to the page before hp.com), while in Safari/WebKit.org
nightlies pressing back from hp.com/#Product goes to hp.com (which
then ends up doing a redirect to a 404).

It therefore seems like there is precedent for not creating a new
session history entry for JS navigation (even when not using
location.replace()) during (or even before) onload, but I'm not seeing
anything about this on
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html

https://webkit.org/b/42861 has more tests, but briefly, the behavior
in the latest stable versions of these browser is:
- Firefox will not create a session history entry if the navigation is
executed inline, or during an onload handler
- Chrome will not create a session history entry if the navigation is
executed inline, or within 5 seconds of the onload handler firing
- Safari will always create a session history entry
- IE will not create a session history entry for hash changes during onload only

My proposed change to WebKit is to not create a session history entry
for location changes that happen before onload fires if they are not
in response to a user gesture. I would also be modifying Chrome to
remove its custom logic for this and just inherit WebKit's.

Does anyone see any compatibility problems with this? Should the HTML5
history section mention anything about navigations caused script vs.
user gestures*? I realize that replace() should obviate the need for
such a heuristic, but given that 1) other browsers seem to do this and
2) sites like hp.com don't get it right, there may be a need for it.

Thanks,

Mihai

* It only alludes to something similar: "In addition, a user agent
could ignore calls to pushState() that are invoked on a timer, or from
event listeners that are not triggered in response to a clear user
action, or that are invoked in rapid succession."