This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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?
(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.
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.
mass-moved component to LC1
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.
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.
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