<div class="gmail_quote">On Thu, Jan 21, 2010 at 3:18 AM, Olli Pettay <span dir="ltr"><<a href="mailto:Olli.Pettay@helsinki.fi">Olli.Pettay@helsinki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 1/21/10 11:12 AM, Darin Fisher wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In WebKit, history.back() is currently implemented asynchronously.<br>
<br>
However, it was not always this way.  Previously, if the back navigation<br>
corresponded to a hash change, then the back navigation would complete<br>
synchronously.  If the back navigation corresponded to a different<br>
document, then it would be completed asynchronously.<br>
<br>
The HTML5 spec currently calls for the old behavior of WebKit, which<br>
happens to match the behavior of Gecko.  Because the spec is written<br>
this way, there is movement in WebKit to change WebKit back.<br>
<br>
IE however appears to implement history.back() asynchronously in all<br>
cases just like newer versions of WebKit.<br>
<br>
I actually think this is a better behavior to spec for a couple reasons:<br>
<br>
1)  It allows for history.back() to behave consistently regardless of<br>
the type of navigation.<br>
2)  It allows for the back/forward list to be decoupled from the main<br>
thread of the rendering engine.<br>
<br>
This last point is quite relevant to Chrome since we store the<br>
back/forward list in a separate process.  We do this since items in the<br>
back/forward list may actually need to be rendered using different<br>
WebKit processes.  (Navigating in the location bar is a hint that we can<br>
spawn a new process.)<br>
<br>
We could copy the entire back/forward list to each process and replicate<br>
state, but that seems excessive.  Instead, simply matching the<br>
history.back() behavior of IE avoids the need to do so.<br>
<br>
 From a web compat perspective, it seems wise to match the behavior of<br>
IE.  It also has other benefits.<br>
<br>
Can we change the spec?<br>
<br>
-Darin<br>
</blockquote>
<br>
<br></div></div>
Do you propose to make all history traversal async?<br>
back/forward/go/location.reload  ?<br><font color="#888888">
<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#888888"><br></font></font></font></blockquote><div><br></div><div>My proposal is to only make history.{back,forward,go} asynchronous.</div>
<div><br></div><div>I haven't carefully reviewed location.reload, but off hand, I think it should</div><div>behave similarly to location assignment.</div><div><br></div><div>My concern is really that the history traversal algorithm should not require</div>
<div>direct synchronous read access to session history entries other than the</div><div>current session history entry.</div><div><br></div><div>I think it would be best for history.{back,forward,go} to be asynchronous</div>
<div>to support an implementation that just sends an event all the way up to</div><div>the UI layer of a browser to synthesize a click of the corresponding buttons.</div><div>That way an implementation can reuse most of the same code paths for</div>
<div>both user initiated history traversal as well as page initiated history traversal.</div><div><br></div><div>-Darin </div></div>