[whatwg] history.back()

On Fri, 22 Jan 2010, Darin Fisher wrote:
> On Fri, Jan 22, 2010 at 2:08 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 21 Jan 2010, Darin Fisher wrote:
> > >
> > > In WebKit, history.back() is currently implemented asynchronously.
> >
> > It's not clear to me what you mean by "asynchronously".
> >
> > Do you mean that the events fire asynchronously? That the Location 
> > object is updated asynchronously? That the decision about whether the 
> > call is a noop or not is fired asynchronously? That the navigation, if 
> > one is necessary, is done asynchronously? Are we talking about 
> > same-frame, or cross-frame? Same-origin, or cross-origin? Traversal 
> > from one entry in one document to another entry in the same document, 
> > or in another document?
> 
> To clarify:
> 
> history.{back,forward,go} begin by scheduling a task on the current 
> thread to run later.  From that task, the history traversal algorithm is 
> executed.

Ah, ok.


> > Another is what should happen if a page goes back() past its fragment 
> > identifier entries, and then modifies the document or alerts the 
> > location? What location should it get? Which document should it 
> > mutate? (test 007)
> >
> > How about:
> >
> >   location.hash = 'a';
> >   /* spin event loop */
> >   history.back();
> >   location.hash = 'b';
> >   history.forward();
> >   alert(location.hash);
> >   /* spin event loop */
> >   alert(location.hash);
> 
> It would be nice if the navigation and history traversal algorithms did 
> not proceed while the page is blocked on a modal alert.

Sure, but what should alert?

I guess you're saying we should have "b" and "b" here.


> > How about:
> >
> >   location.hash = 'x';
> >   location.hash = 'a';
> >   /* spin event loop */
> >   history.back();
> >   /* spin event loop */
> >   history.forward();
> >   location.hash = 'b';
> >   /* spin event loop */
> >   history.back();
> >   /* spin event loop */
> >   alert(location.hash);
> >
> > What does this alert? (test 010)

For this I guess you are saying we should alert "x"?


> I think it would be risky to make navigation to fragment identifiers 
> asynchronously set Location.  All browsers do so synchronously today, so 
> I wouldn't be surprised to find that it matters.

Ok, but when should the session history be traversed? Synchronously or 
not?

If you do:

   location.hash = 'a';
   location.hash = 'b';

...and then spin the event loop, then the user hits "back", do you end up 
at "a", or did "a" never get added to the history?

If you do:

   history.back();
   location.hash = 'a';

...do you end up with a no-op (synchronously traverse history to #a while 
the script is running, then go back in a task), or do you end up at a 
different page (go back to the previous page in a task, then do nothing 
with the location.href because the task for traversing its history is 
tossed when you switch to another page)? Or something else?

If location changes traverse synchronously, there doesn't seem to be any 
benefit to making history.back() asynchronous -- it's the same algorithm.


> > Should Location be set synchronously but with the session history 
> > actually being updated asynchronously using a task, so that .back() 
> > and .forward() calls get interleaved with the Location setter?
> 
> I think this would be problematic in other cases.  Imagine this 
> scenario:
> 
> location="#a";
> pushState("b", "b", "#b");
> location="#c";  // generates a synchronous popstate event

(I assume you mean a hashchange event, not popstate.)

We can have synchronous traversal with asynchronous event dispatch, so I 
don't think that's really a problem.


> > Should document.open() synchronously clear the session history, or 
> > should it asynchronously queue a task and do it that way? Should we, 
> > instead of using tasks that could run much later (e.g. if the script 
> > has previously invoked a bunch of setTimeout(0)s), add a step to the 
> > event loop so that after each task, any history traversal that's been 
> > queued up gets processed immediately?
> 
> non-FIFO queuing makes me nervous ;-)

It's not clear to me exactly what you want specced. Changing the location 
without traversing makes me pretty nervous (more so than non-FIFO 
queueing), but I don't know if that's what you want.

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

Received on Wednesday, 27 January 2010 15:26:43 UTC