<div class="gmail_quote">On Wed, Jan 27, 2010 at 3:26 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div><div class="im">
> > Another is what should happen if a page goes back() past its fragment<br>
> > identifier entries, and then modifies the document or alerts the<br>
> > location? What location should it get? Which document should it<br>
> > mutate? (test 007)<br>
> ><br>
> > How about:<br>
> ><br>
> >   location.hash = 'a';<br>
> >   /* spin event loop */<br>
> >   history.back();<br>
> >   location.hash = 'b';<br>
> >   history.forward();<br>
> >   alert(location.hash);<br>
> >   /* spin event loop */<br>
> >   alert(location.hash);<br>
><br>
> It would be nice if the navigation and history traversal algorithms did<br>
> not proceed while the page is blocked on a modal alert.<br>
<br>
</div>Sure, but what should alert?<br>
<br>
I guess you're saying we should have "b" and "b" here.<br></blockquote><div><br></div><div>Yeah, exactly.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
<br>
> > How about:<br>
> ><br>
> >   location.hash = 'x';<br>
> >   location.hash = 'a';<br>
> >   /* spin event loop */<br>
> >   history.back();<br>
> >   /* spin event loop */<br>
> >   history.forward();<br>
> >   location.hash = 'b';<br>
> >   /* spin event loop */<br>
> >   history.back();<br>
> >   /* spin event loop */<br>
> >   alert(location.hash);<br>
> ><br>
> > What does this alert? (test 010)<br>
<br>
</div>For this I guess you are saying we should alert "x"?<br></blockquote><div><br></div><div>Yes.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
<br>
> I think it would be risky to make navigation to fragment identifiers<br>
> asynchronously set Location.  All browsers do so synchronously today, so<br>
> I wouldn't be surprised to find that it matters.<br>
<br>
</div>Ok, but when should the session history be traversed? Synchronously or<br>
not?<br>
<br>
If you do:<br>
<br>
   location.hash = 'a';<br>
   location.hash = 'b';<br>
<br>
...and then spin the event loop, then the user hits "back", do you end up<br>
at "a", or did "a" never get added to the history?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>In the example you gave above,</div><div><br></div><div>location.hash = 'a'  // appends "#a" to session history</div><div>location.hash = 'b'  // appends "#b" to session history</div>
<div>spin the event loop  // not significant</div><div>user hits "back"  // queues a task on the event loop to traverse session history back one step</div><div>spin the event loop  // "#a" is the current session history entry</div>
<div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
If you do:<br>
<br>
   history.back();<br>
   location.hash = 'a';<br>
<br>
...do you end up with a no-op (synchronously traverse history to #a while<br>
the script is running, then go back in a task), or do you end up at a<br>
different page (go back to the previous page in a task, then do nothing<br>
with the location.href because the task for traversing its history is<br>
tossed when you switch to another page)? Or something else?<br></blockquote><div><br></div><div>Hmm, good question... I'm not sure how much this matters.</div><div><br></div><div>That said, I think it would be good for location.hash = 'a' to interrupt the</div>
<div>history.back() request.  The net result being that "#a" is appended to</div><div>session history, and the history.back() request is discarded.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
If location changes traverse synchronously, there doesn't seem to be any<br>
benefit to making history.back() asynchronous -- it's the same algorithm.<br>
<div class="im"><br></div></blockquote><div><br></div><div>I don't follow this implication.  Can you clarify?</div><div><br></div><div>I'm trying to treat history,{back,forward,go} as a UI command to the navigator.  Synthesize</div>
<div>the user clicking on the corresponding back/forward buttons.  UI actions typically do not</div><div>get dispatched during JS execution (ignoring window.showModalDialog of course).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<br>
> > Should Location be set synchronously but with the session history<br>
> > actually being updated asynchronously using a task, so that .back()<br>
> > and .forward() calls get interleaved with the Location setter?<br>
><br>
> I think this would be problematic in other cases.  Imagine this<br>
> scenario:<br>
><br>
> location="#a";<br>
> pushState("b", "b", "#b");<br>
> location="#c";  // generates a synchronous popstate event<br>
<br>
</div>(I assume you mean a hashchange event, not popstate.)<br></blockquote><div><br></div><div>Oops, yes.  This is a bad example.  Nevermind.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
We can have synchronous traversal with asynchronous event dispatch, so I<br>
don't think that's really a problem.<br>
<div class="im"><br>
<br>
> > Should document.open() synchronously clear the session history, or<br>
> > should it asynchronously queue a task and do it that way? Should we,<br>
> > instead of using tasks that could run much later (e.g. if the script<br>
> > has previously invoked a bunch of setTimeout(0)s), add a step to the<br>
> > event loop so that after each task, any history traversal that's been<br>
> > queued up gets processed immediately?<br>
><br>
> non-FIFO queuing makes me nervous ;-)<br>
<br>
</div>It's not clear to me exactly what you want specced. Changing the location<br>
without traversing makes me pretty nervous (more so than non-FIFO<br>
queueing), but I don't know if that's what you want.<br></blockquote><div><br></div><div>I agree that we should not change the location without traversing history.</div><div><br></div><div>I'm arguing for making history.{back,forward,go} start out by dispatching a task</div>
<div>to then run the history traversal algorithm.  So, history.back() would never change</div><div>the location synchronously.</div><div><br></div><div>-Darin</div><div><br></div><div><br></div><div><br></div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Ian Hickson               U+1047E                )\._.,--....,'``.    fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a>       U+263A                /,   _.. \   _\  ;`._ ,.<br>
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'<br>
</div></div></blockquote></div><br>