12707 2011-05-19 19:56:33 +0000 pushState() / popstate API still not fully updated to match Firefox implementation 2011-09-22 23:23:34 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified PC All RESOLVED FIXED P2 blocker --- 1 jonas ian ian justin.lebar mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 48648 0 jonas 2011-05-19 19:56:33 +0000 The spec seems to still call for 'popstate' to fire on *all* history navigations. That wasn't really what bug 12277 called for, or what we do in firefox. What I propose (and what we do in firefox) was to make popstate *only* fire during in-Document navigations. I.e. only when making history navigations within the same Document. When loading a new document, or when going back to a previous Document, only 'load'/'pageshow' is fired. 49939 1 ian 2011-06-20 19:52:07 +0000 Ah, that wasn't clear. Will fix this too. (I guess the way to do it is to track the current state and if the history is being navigated to that state, don't fire popstate, or something. Would that handle #frag navs correctly?) How should going back multiple steps in history, crossing a document boundary, be handled? e.g.: ...state3 | state4 | state5 ] [ state0 | state1 | state2... where the first [..] is doc A and the second [..] is doc B, and the user navigates from state1 in docB to state4 in docA in one traversal operation. What popstates should fire, if any? How about state5->state3 or state3->state5? 49946 2 jonas 2011-06-21 00:06:08 +0000 (In reply to comment #1) > Ah, that wasn't clear. Will fix this too. (I guess the way to do it is to track > the current state and if the history is being navigated to that state, don't > fire popstate, or something. Would that handle #frag navs correctly?) For each Document you need to keep track of it's current session-history entry. If you end up navigating to a sesssion-history entry which isn't the current session-history entry for its Document, then fire popstate and make the new session-history entry the current session-history entry for that Document. > How should going back multiple steps in history, crossing a document boundary, > be handled? > > e.g.: > > ...state3 | state4 | state5 ] [ state0 | state1 | state2... > > where the first [..] is doc A and the second [..] is doc B, and the user > navigates from state1 in docB to state4 in docA in one traversal operation. > What popstates should fire, if any? Depends on the state of things before that navigation happens. Usually it will fire a popstate on doc A with history.state set to state4. However, if the user had just navigated directly from state4 of docA to state1 of docB, then no popstates fire. > How about state5->state3 or state3->state5? These always fire popstate with history.state set to state3 for the former and state5 for the latter. 49947 3 jonas 2011-06-21 00:11:13 +0000 Note that Firefox currently has some bugs with regards to multi-session-history jumps and documents being stored in the bfcache (basically we miss the fact that a Document exists in the bfcache and we reload from network). There is a patch in bug 646641 if you really want to try it. 52573 4 mike 2011-08-04 05:02:45 +0000 mass-moved component to LC1 54622 5 ian 2011-08-10 19:45:42 +0000 This should be pretty straight-forward. I just need to define a per-Document state whose value is a session history entry, initially set to be the first entry. Whenever transitioning in session history, compare old value to new value in the current popstate step, and if it's different, fire the event and update the value. 57198 6 ian 2011-09-22 23:23:21 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. 57199 7 contributor 2011-09-22 23:23:34 +0000 Checked in as WHATWG revision r6564. Check-in comment: Make popstate not fire onload and not fire when you go back and forth across documents without changing which was the last active state for that document. This is intended to match Firefox. It's also much more sensible than what we had before. http://html5.org/tools/web-apps-tracker?from=6563&to=6564