[whatwg] question about the popstate event

[Justin Lebar]

If I'm understanding the bug correctly, Brady is suggesting not that a
popstate event isn't fired when we navigate back to a document which
has been unloaded from memory, but that the state object in that
popstate event is null.

As I understand it, the crux of his argument relates to the algorithm
to "update the session history with the new page" [1]:

>    2) If the navigation was initiated for entry update of an entry
>
>       1) Replace the entry being updated with a new entry representing
>          the new resource and its Document object and related state.

I think he's arguing that the set of "related state" that is copied to
the new entry does not contain the state object.  His evidence for
this is mostly textual: This state is referenced in other parts of the
spec, and in those places, it's made clear that the state consists of
scroll position and form fields:

(From comment #4 at https://bugs.webkit.org/show_bug.cgi?id=33224)
> I believe "state" in this context is not referring to "state objects", but
> rather "persisted user state" as set forth in 5.11.9 step 3:
> "For example, some user agents might want to persist the scroll position, or
> the values of form controls."

I think this is a good point from a textual perspective.

But I think it's clear that we actually want to persist state objects
across Document unloads.  If we didn't care about this use case, we
could do away with state objects altogether.  A document could just
call pushstate with no state variable and store its state objects in a
global variable indexed by an identifier in the URL.  When the page
receives a popstate, it checks its URL and grabs the relevant state
object.  Simple.  (This doesn't handle multiple entries with the same
URL, but hash navigation doesn't handle that either, so that's not a
big problem.)

My point is that state objects are pretty much useless unless you
persist them after the document has been unloaded.

I also think the fact that we take the structured clone of a state
object before saving it (and that structured clone forbids pointers to
DOM objects and whatnot) indicates that the spec intended for state
objects to stick around after document unload.  Otherwise, why bother
making a restrictive copy?

(It should go without saying that if you're saving state objects
across document unloads, you should also be saving the "has same
document" relationships between history entries.  That is, suppose
history entry A calls pushstate and creates history entry B.  Some
time later, the document for A and B is unloaded, then the user goes
back to B, which is re-fetched into a fresh Document.  Then the user
clicks back, activating A.  We should treat the activation of A from B
as an activation between two entries with the same document, and not
re-fetch A.)

Where the spec needs to be clarified to support this, I think it
should be.  But let's first agree that this is the right thing to do.

-Justin

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page

On Tue, Jan 12, 2010 at 3:54 PM, Darin Fisher <darin at chromium.org> wrote:
> Hi,
> I've been discussing this issue with Brady Eidson over
> at https://bugs.webkit.org/show_bug.cgi?id=33224,
> and his interpretation appears to be different.  (I think he may have
> convinced me too.)
> I'd really like some help understanding how pushState is intended to work
> and to see how that lines up
> with the spec.
> Also, assuming Brady is correct, then I wonder why pushState was designed
> this way.  It seems strange
> to me that entries in session history would disappear when you navigate away
> from a document that used
> pushState.
> -Darin
>
> On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar <justin.lebar at gmail.com> wrote:
>>
>> > From my reading of the spec, I would expect the following steps:
>> > 5. Page A is loaded.
>> > 6. The load event for Page A is dispatched.
>> > 7. The popstate event for Page A is dispatched.
>>
>> I think this is correct.  A popstate event is always dispatched
>> whenever a new session history entry is activated (6.10.3).
>>
>> -Justin
>>
>> On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher <darin at chromium.org> wrote:
>> > I'd like to make sure that I'm understanding the spec for pushState and
>> > the
>> > popstate event properly.
>> > Suppose, I have the following sequence of events:
>> > 1. Page A is loaded.
>> > 2. Page A calls pushState("foo", null).
>> > 3. The user navigates to Page B.
>> > 4. The user navigates back to Page A (clicks the back button once).
>> > Assuming the document of Page A was disposed upon navigation to Page B
>> > (i.e., that it was not preserved in a page cache), should a popstate
>> > event
>> > be generated as a result of step 4?
>> > From my reading of the spec, I would expect the following steps:
>> > 5. Page A is loaded.
>> > 6. The load event for Page A is dispatched.
>> > 7. The popstate event for Page A is dispatched.
>> > Do I understand correctly?
>> > Thanks,
>> > -Darin
>
>