[whatwg] history.back()

[Ian Hickson]

On Fri, 29 Jan 2010, Olli Pettay wrote:
> On 1/29/10 3:32 AM, Ian Hickson wrote:
> > 
> > I've tried to spec this. There is a high risk of compatibility issues, 
> > so I would very much welcome feedback from implementors who try to 
> > implement this.
> > 
> > The main goal of the change here is to make it possible to implement 
> > this (if not completely sanely, but it's the Web, there's only so much 
> > I can do) in a situation with each browsing context having its own 
> > process, as seen to some extent in IE and Chrome, and as is being 
> > examined by other browser vendors also.
>
> So why sync history isn't possible in IE or Chrome?

Anything's _possible_, it's just that it's a lot more complicated. As 
Jonas said earlier in the thread, making history traversal asynchronous is 
likely to make things easier for Mozilla too. Sorry for overstating the 
case above, I have a tendency to exaggerate!


> How should UA handle this case? User presses back (which hopefully does 
> pretty much the same as history.back()) but web page has some loop like 
> script which sets location.hash all the time.

I would recommend that implementations prioritise tasks queued by user 
interaction, so that the script does not preempt the user's action. 
However, since that is a user interface issue, the spec does not specify 
it in any detail. (The spec doesn't require that you expose a back button 
at all.)


> > If we can't do this asynchronously, it's going to really suck for 
> > multiprocess UAs,
>
> Depends for example on whether UA wants to put different domains in same 
> tab to different processes. And even if it does do, synchronous 
> back()/forward() should be possible. Maybe just not as easy. So I'm not 
> sure that "suck for multiprocess UAs" is a really good argument here.

Certainly it isn't well-expressed, but it does seem important to make sure 
that the technology we are specifying can be sanely implemented in a 
multi-process architecture, since two UAs are already shipping with that 
technology, and at least one other (Mozilla) is working on a similar 
effort. I don't think anyone would deny that there are advantages to such 
an approach.


> Uh, changing hashchange again to async. We must stop changing that all 
> the time. Though in this case I like the change. I never really 
> understood the sync hashchange, or the reasoning why it was changed to 
> be sync.

Yeah, my apologies for the back-and-forth on this particular issue. I try 
to minimise churn in general, but in this case I failed.


> So history.back(); history.back(); would queue 2 tasks?

Yes.


> And first one document is loaded (maybe from bfcache), and it could
> synchronously do something like dispatch pageshow or whatever which
> could do things like alert() and then second document was loaded at somepoint.
> Kind of strange way to handle history.back().

For cross-document loads, back() has always been asynchronous, so I don't 
think that particular case is a change.

I agree that it is not completely intuitive.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'