[Bug 12707] popstate API still not fully updated to match Firefox implementation

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12707

--- Comment #2 from Jonas Sicking <jonas@sicking.cc> 2011-06-21 00:06:08 UTC ---
(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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 21 June 2011 00:06:15 UTC