Bug 33823 - Associating a new document object with a history entry that used to share Document objects with other history entries needs to restore that shared association.
Summary: Associating a new document object with a history entry that used to share Doc...
Status: RESOLVED DUPLICATE of bug 33224
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-18 18:59 PST by Brady Eidson
Modified: 2010-01-22 10:10 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brady Eidson 2010-01-18 18:59:50 PST
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.
Comment 1 Darin Fisher (:fishd, Google) 2010-01-22 00:37:59 PST
This is a dupe of bug 33224, right?
Comment 2 Brady Eidson 2010-01-22 10:09:31 PST
(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.
Comment 3 Brady Eidson 2010-01-22 10:10:41 PST

*** This bug has been marked as a duplicate of bug 33224 ***