[whatwg] history.back()

[Darin Fisher]

On Wed, Jan 27, 2010 at 3:26 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> > > 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.
>

Yeah, exactly.



>
>
> > > 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"?
>

Yes.



>
>
> > 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?
>

I think that location.hash = 'a' should synchronously add "#a" to the
session history, or at least it should appear to the web page that it was
added synchronously.

In the example you gave above,

location.hash = 'a'  // appends "#a" to session history
location.hash = 'b'  // appends "#b" to session history
spin the event loop  // not significant
user hits "back"  // queues a task on the event loop to traverse session
history back one step
spin the event loop  // "#a" is the current session history entry





>
> 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?
>

Hmm, good question... I'm not sure how much this matters.

That said, I think it would be good for location.hash = 'a' to interrupt the
history.back() request.  The net result being that "#a" is appended to
session history, and the history.back() request is discarded.



>
> If location changes traverse synchronously, there doesn't seem to be any
> benefit to making history.back() asynchronous -- it's the same algorithm.
>
>
I don't follow this implication.  Can you clarify?

I'm trying to treat history,{back,forward,go} as a UI command to the
navigator.  Synthesize
the user clicking on the corresponding back/forward buttons.  UI actions
typically do not
get dispatched during JS execution (ignoring window.showModalDialog of
course).



>
> > > 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.)
>

Oops, yes.  This is a bad example.  Nevermind.



>
> 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.
>

I agree that we should not change the location without traversing history.

I'm arguing for making history.{back,forward,go} start out by dispatching a
task
to then run the history traversal algorithm.  So, history.back() would never
change
the location synchronously.

-Darin






>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100127/2cf8e6b9/attachment-0002.htm>