[whatwg] history.back()

On Thu, Jan 21, 2010 at 1:12 AM, Darin Fisher <darin at chromium.org> 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?

Sounds good to me. Having all navigation be asynchronous I suspect
would have implementations benefits in Gecko too.

/ Jonas

Received on Thursday, 21 January 2010 01:16:17 UTC