[whatwg] When are sandboxing flags set?

[Ian Hickson]

On Thu, 24 Jun 2010, Ben Lerner wrote:
>
> The 22 June 2010 spec says in section 6.5.1 Navigating across documents:
> 
> If the source browsing context is not the same as the browsing context 
> being navigated, ..., and the source browsing context had its sandboxed 
> navigation browsing context flag set when its active document was 
> created, then abort these steps.
> 
> When exactly is its active document created?

For HTML documents, it happens as part of the navigation algorithm, when 
it parses the HTML file (first sentence):

   http://www.whatwg.org/specs/web-apps/current-work/complete.html#read-html


> I can read this clause in several ways:
> 
> * When documents are created they must set the sandboxed navigation 
> browsing context flag on their browsing context.  But documents are 
> created before they are active in some browsing context, so that seems 
> wrong.
> 
> * When documents are set as active within a browsing context.  But that 
> doesn't sound like "creation" time, so that seems wrong too.
> 
> * At the instant the document was allocated, the browsing context 
> happened to record its current context flags despite the document not 
> being active in the browsing context yet.  But that seems implausible at 
> best.

It's the latter, at least as specced. Why is it implausible?


> Additionally, the sandboxing flags seem to be more a feature of the 
> <iframe> element than of the browsing context, because they depend on 
> the value of the <iframe>'s sandbox attribute.  Can these flags ever be 
> set on a top-level browsing context?  No, correct?

Currently, yes, but there's no reason for that to remain the case.


> The spec then talks about the seamless browsing context flag.  Is this 
> flag distinct from the sandbox-seamless-iframes flag?  And when is this 
> flag set?

Yes, the two are distinct. It is set automatically when the iframe has the 
seamless attribute set, as per the <iframe> section.


> It seems different from the others, because it can be set by 
> manipulating content attributes:
> 
> Specifically, when the attribute is set on an iframe element whose owner 
> Document's browsing context did not have the sandboxed seamless iframes 
> flag set when that Document was created, and while either the browsing 
> context's active document has the same origin as the iframe element's 
> document, or the browsing context's active document's address has the 
> same origin as the iframe element's document, the following requirements 
> apply:
> 
>                 The user agent must set the seamless browsing context 
> flag to true for that browsing context. This will cause links to open in 
> the parent browsing context.
> 
> WARNING! It is important that user agents recheck the above conditions 
> whenever the active document of the nested browsing context of the 
> iframe changes, such that the seamless browsing context flag gets unset 
> if the nested browsing context is navigated to another origin.
> 
> Again the question of "when the document was created".  Additionally, 
> the seamless flag refers to the iframe, the iframe's owner document, the 
> iframe's owner document's browsing context, and the iframe's browsing 
> context itself.  These don't seem intrinsically like flags on the 
> browsing context...

Well they're only set on browsing contexts that are inside iframes, and 
there's a 1:1 mapping of <iframe> to browsing context, so you could look 
at it either way. I just did it in terms of the browsing context since 
that's more flexible and doesn't require us to keep checking for an 
iframe.


> Are there any other flags that might apply to browsing contexts that 
> might equally well apply to iframes instead?

I can't think of any off-hand.


On Wed, 23 Jun 2010, Adam Barth wrote:
>
> [...] how we interpreted this on WebKit:
> 
> 1) When a Document object is allocated, it is either associated with a 
> browsing context (which we call a Frame) or it isn't.  It's an invariant 
> that a Document object can never become an active document of a Frame 
> unless the Document was associated with that Frame when it was 
> allocated.

This is the case in the spec also.


> 2) If the Document object is associated with a Frame, then we check 
> whether that Frame is an <iframe> element in another document.
>
> 3) If so, we copy the sandbox bits from the <iframe> element into the 
> document, "freezing" them.

This seems conformant.

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