Apologies for the verbose summary. Associating a new document object with a history entry that used to share Document objects with other history entries needs to restore that association.
According to 6.10.1 of HTML5:
"Entries that have had their Document objects discarded must, for the purposes of the algorithms given below, act as if they had not. When the user or script navigates back or forwards to a page which has no in-memory DOM objects, any other entries that shared the same Document object with it must share the new object as well."
Imagine the following scenario.
1 - Load an HTML document that is not eligible for the page cache, creating Document object A. It is associated with the current history entry #1.
2 - Call pushState(). A second entry #2 is added, also associated with Document object A.
3 - Navigate away from Document object A to a completely new HTML document, creating Document object B. Document object A is destroyed, and its association with history entries #1 and #2 is removed.
4 - Traverse the history back to entry #2. A new Document object C is created. We see #2 is a state object and will queue the popstate event on Document object C.
At this point, history entry #1 is not formally associated with Document object C. In fact, if the pushState() call in step #2 included a URL argument, we might actually perform a navigation in case of a history traversal from entry #2 to entry #1.
The language in the spec is meant to associate Document object C with both entries #1 and #2 in step 4. This is so another traversal from entry #2 to entry #1 will simply cause a popstate event, and not an actual navigation.
For the above reason, applications built heavily around this API will suffer direly if this bug is not fixed.
This is a dupe of bug 33224, right?
(In reply to comment #1)
> This is a dupe of bug 33224, right?
Hmmm Wonder how that happened.
I fixed the "Navigating back to a new document doesn't get popstate" in https://bugs.webkit.org/show_bug.cgi?id=33571 and filed this one as a follow up, completely neglecting 33224
I agree this is a dupe of what 33224 is currently being used for, but we need to retitle it to make it clear the remaining problem it's solving is the chain-of-state-entries problem.
*** This bug has been marked as a duplicate of bug 33224 ***