[Webkit-unassigned] [Bug 41372] popstate event is not fired until document opts in by calling pushstate.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=41372





--- Comment #7 from Justin Lebar <justin.lebar+bug at gmail.com>  2010-08-24 16:47:03 PST ---
(In reply to comment #6)
> Justin, it looks like your test case at http://people.mozilla.org/~jlebar/test/webkit/popstate-load.html is no longer there. I've attached a (hopefully) similar test case.

Sorry; I accidentally nuked my webspace a few weeks ago.  Your testcase looks similar.

> The output from Webkit is:
> 
> setting hash to #foo
> going back
> test complete
> 
> The output from Firefox 4.0b4:
> 
> popstate: null
> setting hash to #foo
> popstate: null
> going back
> popstate: null
> test complete
> 
> It seems to be like Gecko is firing popstate too often here. We only actually do history traversal when going back (to the first entry in the document), so I would expect to only see the final popstate log line.

I don't think "history traversal" means "go to a page you've been to before."  You can traverse the history to a page you've never visited before.

I checked with Hixie about this on #whatwg:

<Hixie> there are exactly two times popstate is fired
<Hixie> 1. during history traversal, if the document readiness is already "complete"
<Hixie> 2. after the browser stops parsing

(1) corresponds to http://www.whatwg.org/specs/web-apps/current-work/#history-traversal
(2) corresponds to http://www.whatwg.org/specs/web-apps/current-work/#the-end

The first popstate happens after we finish parsing the document.  Then when we set the hash to #foo.  This causes us to run algorithm 6.5.8 "Navigating to a fragment identifier" which causes a history traversal and a popstate.  Then we go back, which is also a history traversal.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.