[whatwg] When are sandboxing flags set?

[Adam Barth]

On Wed, Jun 23, 2010 at 6:05 PM, Ben Lerner <t-benle at microsoft.com> 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.
>
> (emphasis mine.)  When exactly is its active document created?  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.

I'm not 100% sure how this all works in the spec, but I can tell you
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.
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.

I'm not sure which of your bullets that corresponds to, but it looks
like a mix of your first and third bullets.  The second bullet is
definitely wrong because it's an invariant of the system that the
sandbox flags of a Document can never change after they are
initialized.

> 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, there is no way to set sandbox attributes on a top-level
browsing context.  However, one could imagine a future in which such
an API existed.

> 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?  It seems different from the others, because it can be set by
> manipulating content attributes:

WebKit doesn't implement seamless yet, so I'm not how this all works.

Kind regards,
Adam


> 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…
>
>
>
> Are there any other flags that might apply to browsing contexts that might
> equally well apply to iframes instead?