<div>On Tue, Jan 12, 2010 at 7:30 PM, Justin Lebar <span dir="ltr"><<a href="mailto:justin.lebar@gmail.com">justin.lebar@gmail.com</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If I'm understanding the bug correctly, Brady is suggesting not that a<br>
popstate event isn't fired when we navigate back to a document which<br>
has been unloaded from memory, but that the state object in that<br>
popstate event is null.<br>
<br>
As I understand it, the crux of his argument relates to the algorithm<br>
to "update the session history with the new page" [1]:<br>
<br>
> 2) If the navigation was initiated for entry update of an entry<br>
><br>
> 1) Replace the entry being updated with a new entry representing<br>
> the new resource and its Document object and related state.<br>
<br>
I think he's arguing that the set of "related state" that is copied to<br>
the new entry does not contain the state object. His evidence for<br>
this is mostly textual: This state is referenced in other parts of the<br>
spec, and in those places, it's made clear that the state consists of<br>
scroll position and form fields:<br>
<br>
(From comment #4 at <a href="https://bugs.webkit.org/show_bug.cgi?id=33224" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=33224</a>)<br>
> I believe "state" in this context is not referring to "state objects", but<br>
> rather "persisted user state" as set forth in 5.11.9 step 3:<br>
> "For example, some user agents might want to persist the scroll position, or<br>
> the values of form controls."<br>
<br>
I think this is a good point from a textual perspective.<br>
<br></blockquote><div><br></div><div>Ah, yes... agreed.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
But I think it's clear that we actually want to persist state objects<br>
across Document unloads. If we didn't care about this use case, we<br>
could do away with state objects altogether. A document could just<br>
call pushstate with no state variable and store its state objects in a<br>
global variable indexed by an identifier in the URL. When the page<br>
receives a popstate, it checks its URL and grabs the relevant state<br>
object. Simple. (This doesn't handle multiple entries with the same<br>
URL, but hash navigation doesn't handle that either, so that's not a<br>
big problem.)<br>
<br>
My point is that state objects are pretty much useless unless you<br>
persist them after the document has been unloaded.<br></blockquote><div><br></div><div>Right! This is the very perspective I viewed pushState from, and it also</div><div>seems to me that the feature is far less useful if state objects are not</div>
<div>persisted after document unload.</div><div><br></div><div>-Darin</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I also think the fact that we take the structured clone of a state<br>
object before saving it (and that structured clone forbids pointers to<br>
DOM objects and whatnot) indicates that the spec intended for state<br>
objects to stick around after document unload. Otherwise, why bother<br>
making a restrictive copy?<br>
<br>
(It should go without saying that if you're saving state objects<br>
across document unloads, you should also be saving the "has same<br>
document" relationships between history entries. That is, suppose<br>
history entry A calls pushstate and creates history entry B. Some<br>
time later, the document for A and B is unloaded, then the user goes<br>
back to B, which is re-fetched into a fresh Document. Then the user<br>
clicks back, activating A. We should treat the activation of A from B<br>
as an activation between two entries with the same document, and not<br>
re-fetch A.)<br>
<br>
Where the spec needs to be clarified to support this, I think it<br>
should be. But let's first agree that this is the right thing to do.<br>
<br>
-Justin<br>
<br>
[1] <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page</a><br>
<div><div></div><div class="h5"><br>
On Tue, Jan 12, 2010 at 3:54 PM, Darin Fisher <<a href="mailto:darin@chromium.org">darin@chromium.org</a>> wrote:<br>
> Hi,<br>
> I've been discussing this issue with Brady Eidson over<br>
> at <a href="https://bugs.webkit.org/show_bug.cgi?id=33224" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=33224</a>,<br>
> and his interpretation appears to be different. (I think he may have<br>
> convinced me too.)<br>
> I'd really like some help understanding how pushState is intended to work<br>
> and to see how that lines up<br>
> with the spec.<br>
> Also, assuming Brady is correct, then I wonder why pushState was designed<br>
> this way. It seems strange<br>
> to me that entries in session history would disappear when you navigate away<br>
> from a document that used<br>
> pushState.<br>
> -Darin<br>
><br>
> On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar <<a href="mailto:justin.lebar@gmail.com">justin.lebar@gmail.com</a>> wrote:<br>
>><br>
>> > From my reading of the spec, I would expect the following steps:<br>
>> > 5. Page A is loaded.<br>
>> > 6. The load event for Page A is dispatched.<br>
>> > 7. The popstate event for Page A is dispatched.<br>
>><br>
>> I think this is correct. A popstate event is always dispatched<br>
>> whenever a new session history entry is activated (6.10.3).<br>
>><br>
>> -Justin<br>
>><br>
>> On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher <<a href="mailto:darin@chromium.org">darin@chromium.org</a>> wrote:<br>
>> > I'd like to make sure that I'm understanding the spec for pushState and<br>
>> > the<br>
>> > popstate event properly.<br>
>> > Suppose, I have the following sequence of events:<br>
>> > 1. Page A is loaded.<br>
>> > 2. Page A calls pushState("foo", null).<br>
>> > 3. The user navigates to Page B.<br>
>> > 4. The user navigates back to Page A (clicks the back button once).<br>
>> > Assuming the document of Page A was disposed upon navigation to Page B<br>
>> > (i.e., that it was not preserved in a page cache), should a popstate<br>
>> > event<br>
>> > be generated as a result of step 4?<br>
>> > From my reading of the spec, I would expect the following steps:<br>
>> > 5. Page A is loaded.<br>
>> > 6. The load event for Page A is dispatched.<br>
>> > 7. The popstate event for Page A is dispatched.<br>
>> > Do I understand correctly?<br>
>> > Thanks,<br>
>> > -Darin<br>
><br>
><br>
</div></div></blockquote></div><br>