On Jan 12, 2010, at 7:30 PM, Justin Lebar wrote:
> 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
On Tue, Jan 12, 2010 at 7:30 PM, Justin Lebar wrote:
> 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
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
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
> 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 activate
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 bac
