[whatwg] Asynchronous history navigation and some inconsistencies

Thu Jun 28 18:29:55 PDT 2012

On Thu, 9 Feb 2012, Pablo Flouret wrote:
> 
> I'm trying this out:
> 
> <!DOCTYPE html>
> <script>
> window.onpopstate = function (e) { alert(e.state); }
> history.pushState(1, "", "#1");
> history.pushState(2, "", "#2");
> history.back();
> history.pushState(3, "", "#3");
> </script>
> 
> WebKit:
> alerts 2 (bug, i'd say)
> history is #1, #2, #3
> 
> Gecko:
> alerts 1
> history is #1, #3
> 
> Opera:
> Doesn't fire the event (bug?)
> history is #1, #2, #3
> 
> Don't have an IE to test right now, so not sure what happens there.
> 
> What should be happening here ideally?

Per spec, back() is asynchronous, but pushState() is synchronous. So the 
above code is functionally equivalent to this code:

 <script>
  window.onpopstate = function (e) { alert(e.state); }
  history.pushState(1, "", "#1");
  history.pushState(2, "", "#2");
  history.pushState(3, "", "#3");
  history.back();
 </script>

...or this code:

 <script>
  window.onpopstate = function (e) { alert(e.state); }
  history.pushState(1, "", "#1");
  history.pushState(2, "", "#2");
  history.pushState(3, "", "#3");
  setTimeout(function () { history.back(); }, 0);
 </script>

...which is to say, you should get an alert of "2", and the history should 
be #1, #2, #3, with #2 being the document's address at the end.

In your testing, you may find browsers differ if you do the test in a 
timeout after onload than before onload. There have at times been 
requirements that made the behaviour differ before and after the 'load' 
event fired. (These requirements have since been dropped, I believe. 
There's now no difference; the API always acts the same.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'