[Webkit-unassigned] [Bug 33823] New: Associating a new document object with a history entry that used to share Document objects with other history entries needs to restore that association.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33823

           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.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: beidson at apple.com


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.