[whatwg] history.back()

[Darin Fisher]

On Thu, Jan 21, 2010 at 3:18 AM, Olli Pettay <Olli.Pettay at helsinki.fi>wrote:

> 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
>>
>
>
> Do you propose to make all history traversal async?
> back/forward/go/location.reload  ?
>
>
>
My proposal is to only make history.{back,forward,go} asynchronous.

I haven't carefully reviewed location.reload, but off hand, I think it
should
behave similarly to location assignment.

My concern is really that the history traversal algorithm should not require
direct synchronous read access to session history entries other than the
current session history entry.

I think it would be best for history.{back,forward,go} to be asynchronous
to support an implementation that just sends an event all the way up to
the UI layer of a browser to synthesize a click of the corresponding
buttons.
That way an implementation can reuse most of the same code paths for
both user initiated history traversal as well as page initiated history
traversal.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100121/48f38bef/attachment-0001.htm>