[whatwg] HTML5 History Management

Sebastian,
The same-origin is pretty clearly specified, I've included the excerpt  
from the spec below. Your suggestion for clarity on updating Location  
fields in the the UI would be a part of step five in the description  
of pushState in section 6.10.2 is a good one. Ian, I feel like this  
counts as a possible action item.
Nathan

***

Possible Action Items
1. Clarify how the user agent uses the calculated location value from  
the pushState description step 2 in section 6.10.2 in terms of being  
reflected in the Location object.

It is my opinion that this URL should be reflected in the Location  
value. This would imply that it would be reflected in the location bar  
of user agents that have this as part of their UI. It seems that the  
place to include this clarification would be the pushState description  
step 5 in section 6.10.2

2. Clarify that pushState() does not cause navigation.

I read the spec quite a few times and still got this wrong,  
apparently. Making this completely clear would not hurt.


***

If a third argument is specified, run these substeps:
1. Resolve the value of the third argument, relative to the first  
script's base URL.
2. If that fails, raise a SECURITY_ERR exception and abort the  
pushState() steps.
3. Compare the resulting absolute URL to the document's address. If  
any part of these two URLs differ other than the <path>, <query>, and  
<fragment> components, then raise a SECURITY_ERR exception and abort  
the pushState() steps.
For the purposes of the comparison in the above substeps, the <path>  
and <query> components can only be the same if the URLs use a  
hierarchical <scheme>.


On Jul 30, 2009, at 10:27 AM, Sebastian Markb?ge wrote:

> Jonas,
>
> That is my interpretation too. But I think it'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.
>
> Now if the UA is suppose to update the Location field, shouldn't  
> push state URL be subject to same-domain policies? Is that defined  
> clearly?
>
> Otherwise, this can be used during phishing attacks.
>
> Sebastian
>
> On Thu, Jul 30, 2009 at 4:13 PM, Nathan Hammond <nathan at nathanhammond.com 
> > wrote:
> Hey Jonas et al.:
> Thanks for the reply, forgive my disbelief on Clarification 1. :) If  
> I'm completely with you, that is entirely unexpected on my part (and  
> I'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?
>
> This is a behavior I'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'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.
>
> Also, that would imply that the popstate only fires when you're  
> navigating through history. Is that correct?
>
> Thanks!
> Nathan
>
>
> On Jul 30, 2009, at 4:42 AM, Jonas Sicking wrote:
>
> On Wed, Jul 29, 2009 at 7:38 PM, Nathan Hammond<nathan at nathanhammond.com 
> > wrote:
> Clarifications
> 1. window.history.pushState({}, "Title",
> "/path/to/new/file.html?s=newvalue#newhash") replaces the current  
> document
> object with the one specified by the new URL. It then causes the event
> popstate to fire immediately after the load event, correct?
>
> No. The above line with change the uri of the existing document to be
> "http://example.com/path/to/new/file.html?s=newvalue#newhash" (with
> the part before 'path' obviously depending on where the original page
> lives).
>
> So no network activity takes place and the Document node remains the
> same. Also no popstate event is fired.
>
> 2. window.history.pushState({}, "Title", "#newhash") creates a new  
> history
> state object with the specified data object, the specified title,  
> the same
> document object, and a location object that replaces the existing  
> hash with
> "#newhash", correct?
>
> Yes.
>
> / Jonas
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090730/e0eb671b/attachment.htm>

Received on Thursday, 30 July 2009 08:00:49 UTC