[whatwg] history.back()

[Olli Pettay]

And still one thing to test and specify;
if history.back()/forward() is asynchronous,
does that mean that loading start asynchronously,
or that entries are added asynchronously to session history?

What should happen if a page calls:
history.back();
history.forward();

What if the page calls:
history.back();
history.go(-2);


And btw, some of the session history handling is anyway synchronous.
Per the current HTML5 draft calling document.open() adds a new entry to
session history immediately (IIRC, webkit is the only one which doesn't
support this).

So, after all, I'm not yet 100% sure whether making back()/forward()
async is good. This needs some more discussion, and things needs to
be specified properly.


-Olli




On 1/21/10 11: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.
>
>  From a web compat perspective, it seems wise to match the behavior of
> IE.  It also has other benefits.
>
> Can we change the spec?
>
> -Darin