This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24110 - Navigate algorithm doesn't specify explicit action when aborting due to sandboxing in Step 2.
Summary: Navigate algorithm doesn't specify explicit action when aborting due to sandb...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-16 11:51 UTC by Bob Owen
Modified: 2014-01-03 21:33 UTC (History)
4 users (show)

See Also:

Attachments

Description Bob Owen 2013-12-16 11:51:28 UTC 
Currently the navigate algorithm step 2:
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
says that if the source browsing context is not allowed to navigate the browsing context then abort these steps.
However it does not says explicitly what should be done if it aborts, nor do any of the callers of the algorithm as far as I can see.

Gecko currently throws in some circumstances and does nothing in others.
We have a bug to address this and make it throw where possible, as we believe it is better to propagate the error than to fail silently.

It would be good if this could be reflected in the spec, or at least a comment to say that the user agent may throw an InvalidAccessError at this point.

Thanks.
Comment 1 Ian 'Hixie' Hickson 2013-12-16 21:58:45 UTC 
I'm confused. Why would it throw? Do you have a test case demonstrating what you mean? "Abort" here just means that on and no more: "stop doing these steps".
Comment 2 Bobby Holley (:bholley) 2013-12-16 22:03:35 UTC 
(In reply to Ian 'Hixie' Hickson from comment #1)
> I'm confused. Why would it throw?

Because it's generally more helpful to throw an exception than to fail silently? There may be reasons against this that I don't understand, but naively it seems like a reasonable thing to do.

> Do you have a test case demonstrating what
> you mean? "Abort" here just means that on and no more: "stop doing these
> steps".

Right. And Bob is proposing that things like .replace() should throw if they were prevented by sandboxing.
Comment 3 Ian 'Hixie' Hickson 2013-12-16 23:46:12 UTC 
Oh I see, you mean when this is called synchronously from a method. I suppose we can throw if it's not Web-incompatible. What do you want to throw for? Anything that aborts before the algorithm goes async? Anything that aborts before the "gone async" flag starts being checked? Only the first thing that can abort, relating to the sandboxing flags? What if the user later indicates a desire to navigate anyway? What should the exception be, a regular secrutity exception? InvalidState?
Comment 4 Bob Owen 2013-12-17 18:55:29 UTC 
(In reply to Ian 'Hixie' Hickson from comment #3)
> Oh I see, you mean when this is called synchronously from a method. I
> suppose we can throw if it's not Web-incompatible. What do you want to throw
> for?

I was thinking just for Step 2, which relates to the sandboxing flags and I was thinking an InvalidAccessError seems appropriate or perhaps an AbortError.

Nearly all the other cases before it goes async, seem to either be because some other algorithm takes over or because some other action is already happening.
In both these cases, it probably makes sense not to throw to makes sure the other actions are not affected.

As for web-compatibility, I'm not sure, but window.open and location.replace can both throw exceptions for other reasons.
Also, Gecko already throws for window.open, and some others, when blocked because of sandboxing.
Comment 5 Bobby Holley (:bholley) 2013-12-19 18:23:09 UTC 
Naively, the easiest thing for implementors is just to throw for anything that's sync. This allows the sandboxing code to just throw, and let the error propagate up to the caller if it happens to be synchronous script.

Whether it works out conveniently like that in practice I'm not sure, since it depends on the details of the spec algorithms and Gecko's implementation of them, neither of which I have in my head right now. I'll defer to Ian and Bob on that.
Comment 6 contributor 2014-01-03 21:33:51 UTC 
Checked in as WHATWG revision r8370.
Check-in comment: Make the case of an API call trying to navigate a browsing context that it can't navigate due to sandboxing throw a security exception rather than silently fail.
http://html5.org/tools/web-apps-tracker?from=8369&to=8370