[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


Mihai Parparita <mihaip at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mihaip at chromium.org




--- Comment #9 from Mihai Parparita <mihaip at chromium.org>  2010-08-25 14:07:42 PST ---
(In reply to comment #7)
> <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.

Thanks for the explanation, that makes sense.

What about the case where we navigate to two different fragments, and then go back twice (see updated test case attachment)? Gecko fires popstate for both history.back() calls, but it seems like first time (when going back from #state2 to #state1), the specified entry is not the first in the document, and it doesn't have a state object, so the conditions in step 10 of 6.5.9 (http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#history-traversal) don't apply.

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