[whatwg] history.back()

On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jan 21, 2010, at 1:12 AM, Darin Fisher wrote:
>
> > In WebKit, history.back() is currently implemented asynchronously.
> >
> > However, it was not always this way.  Previously, if the back navigation
> corresponded to a hash change, then the back navigation would complete
> synchronously.  If the back navigation corresponded to a different document,
> then it would be completed asynchronously.
> >
> > The HTML5 spec currently calls for the old behavior of WebKit, which
> happens to match the behavior of Gecko.  Because the spec is written this
> way, there is movement in WebKit to change WebKit back.
> >
> > IE however appears to implement history.back() asynchronously in all
> cases just like newer versions of WebKit.
> >
> > I actually think this is a better behavior to spec for a couple reasons:
> >
> > 1)  It allows for history.back() to behave consistently regardless of the
> type of navigation.
> > 2)  It allows for the back/forward list to be decoupled from the main
> thread of the rendering engine.
> >
> > This last point is quite relevant to Chrome since we store the
> back/forward list in a separate process.  We do this since items in the
> back/forward list may actually need to be rendered using different WebKit
> processes.  (Navigating in the location bar is a hint that we can spawn a
> new process.)
> >
> > We could copy the entire back/forward list to each process and replicate
> state, but that seems excessive.  Instead, simply matching the
> history.back() behavior of IE avoids the need to do so.
>
> I don't have strong feelings either way on what the spec should require.
> But I don't see why this is excessive. You'd only have to store fragment
> navigations and pushState navigations, not the full back/forward list. It
> seems like a good idea anyway not to have to serialize state objects back
> and forth.
>

We have to serialize state objects back and forth regardless so that if a
renderer process crashes, we still have the session history.  This allows us
to reload the pages, and restore relevant session history state (e.g.,
scroll position, form field values, and now state objects).



>
> I asked Brady (the Safari/WebKit engineer who implemented pushState())
> about this, and he told me he found that in the pushState case it sometimes
> made things easier from the authoring side for history.back() to be
> synchronous. But I don't have the details.


Brady and I have been discussing this too.  I'm not convinced that
synchronous history.back() makes things significantly better for content
authors.  Indeed, I'm concerned that it makes things worse.

Here's what I mean:  If history.go() sometimes results in the history
traversal completing synchronously (hash change) and sometimes not
(navigation required), then there is a loss of predictability for the
programmer.  They have to deal with event dispatch sometimes happening in a
re-entrant manner, but other times not.  A consistent model seems better to
me.

-Darin



>
> >
> > From a web compat perspective, it seems wise to match the behavior of IE.
>  It also has other benefits.
> >
> > Can we change the spec?
>
>
> Regards,
> Maciej
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100121/c167b768/attachment.htm>

Received on Thursday, 21 January 2010 20:37:39 UTC