<div>Jonas,</div><div><br></div><div>That is my interpretation too. But I think it&#39;s a little unclear whether that means that the UA should update any Location fields in the UI. I understand that this may be optional or outside the scope, but I think that it should still be mentioned.</div>
<div><br></div><div>Now if the UA is suppose to update the Location field, shouldn&#39;t push state URL be subject to same-domain policies? Is that defined clearly?</div><div><br></div><div>Otherwise, this can be used during phishing attacks.</div>
<div><br></div><div>Sebastian</div><div><br></div><div class="gmail_quote">On Thu, Jul 30, 2009 at 4:13 PM, Nathan Hammond <span dir="ltr">&lt;<a href="mailto:nathan@nathanhammond.com">nathan@nathanhammond.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey Jonas et al.:<br>
Thanks for the reply, forgive my disbelief on Clarification 1. :) If I&#39;m completely with you, that is entirely unexpected on my part (and I&#39;ve read this part of the spec a few times). Is this to imply that, no matter what the arguments to pushState(), if the path is relative to the current URL there will be no request for a new document and no user-agent initiated network activity?<br>

<br>
This is a behavior I&#39;m fine with and will meet my needs just as well, I was simply expecting to have to use the approach from Clarification 2 in order to retain my document object. It does however lend itself to some confusion when paired with user agents that don&#39;t yet support the history portions of the spec as they will have to be handled with hash-based addressing while those that support pushState() will have more sane URLs--but that is no matter in the grand scheme of things.<br>

<br>
Also, that would imply that the popstate only fires when you&#39;re navigating through history. Is that correct?<br>
<br>
Thanks!<br><font color="#888888">
Nathan</font><div><div></div><div class="h5"><br>
<br>
On Jul 30, 2009, at 4:42 AM, Jonas Sicking wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jul 29, 2009 at 7:38 PM, Nathan Hammond&lt;<a href="mailto:nathan@nathanhammond.com" target="_blank">nathan@nathanhammond.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Clarifications<br>
1. window.history.pushState({}, &quot;Title&quot;,<br>
&quot;/path/to/new/file.html?s=newvalue#newhash&quot;) replaces the current document<br>
object with the one specified by the new URL. It then causes the event<br>
popstate to fire immediately after the load event, correct?<br>
</blockquote>
<br>
No. The above line with change the uri of the existing document to be<br>
&quot;<a href="http://example.com/path/to/new/file.html?s=newvalue#newhash" target="_blank">http://example.com/path/to/new/file.html?s=newvalue#newhash</a>&quot; (with<br>
the part before &#39;path&#39; obviously depending on where the original page<br>
lives).<br>
<br>
So no network activity takes place and the Document node remains the<br>
same. Also no popstate event is fired.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. window.history.pushState({}, &quot;Title&quot;, &quot;#newhash&quot;) creates a new history<br>
state object with the specified data object, the specified title, the same<br>
document object, and a location object that replaces the existing hash with<br>
&quot;#newhash&quot;, correct?<br>
</blockquote>
<br>
Yes.<br>
<br>
/ Jonas<br>
</blockquote>
<br>
</div></div></blockquote></div><br>