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