[whatwg] Navigation and history traversal issues

[Ian Hickson]

On Thu, 22 Aug 2013, Andrew Oakley wrote:
> On 19/09/12 01:18, Ian Hickson wrote:
> >
> > I've changed the spec so that traversing the history by a delta always 
> > cancels any pending navigations unless you're in the middle of an 
> > unload, in which case it just aborts the algorithm entirely.
> > 
> > I've also made back()/forward()/go() not work during the document's 
> > unload handler, since that could be used for griefing. I'm tempted to 
> > disable it entirely for all docs a la alert(), but I've no idea if 
> > that's Web- compatible and I suspect not.
> 
> I assume this is where steps 3 and 4 of the "traverse the history by a 
> delta" algorithm came from.

Step 3. Step 4 is about canceling an existing navigation if you hit back.


> It's not clear from the spec which browsing context and document these 
> steps refer to.  Is it the "specified browsing context" and the active 
> document of that context (I think that makes most sense)?

Hm. I meant it to be the Document of the History object, but you raise an 
interesting point. This whole thing is rather poorly defined.

I've tried to clear it up.


> Additionally it isn't clear which event loop the task should be 
> associated with.

I've tried to clear this up too. It turns out this wasn't taking into 
account per-frame process isolation, anyway. I had to introduce yet 
another kind of event loop. This does introduce some race conditions in 
UAs with more than one event loop per tab, but I don't know what we can do 
about that without adding in a lot of blocking during traversal, which I 
am guessing wouldn't be popular.


> > Aah, ok. The spec already says that's not allowed. You can't get to 
> > the History object of a cross-origin Window:
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/#security-window
> > 
> > (I forget what the story is if you get a History object from a 
> > same-origin Window, then have the browsing context navigated, then use 
> > the History object you kept around... I expect it is supposed to work 
> > much as if you were to call it on the new, cross-origin, History 
> > object, though.)
> 
> The implication here as that you should never be able to do a history 
> traversal of a browsing context that is not same origin (and so there is 
> only one event loop to choose from).  The "story" about keeping history 
> objects around seems does not seem to be specified anywhere (so the 
> assumption was that it should work as normal).
>
> It looks like some browsers don't let you use history objects you kept 
> around (they should probably throw an InvalidStateError), others let you 
> use them if the current document of the relevant browsing context is 
> same-origin (and should probably throw a SecurityError).
> 
> It's rather awkward to test this, but can we have something in the spec 
> to prevent cross-origin history traversal?  If this is not in the same 
> section as the "traverse the history by a delta" algorithm can we have a 
> note to say that this can never happen cross-origin?

Well, no, not really, because it can. For example, if you have an iframe 
that's cross-origin, and it's navigated, and then you call your own 
History object's back() method, it'll actually traverse that iframe.

But a History object of a non-active Document is a different matter...

Looks like this will need help from WebIDL. I've filed bug 23359 and 
marked it as blocked on bug 23358:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=23359
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=23358

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'