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
