W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2010

[whatwg] When are sandboxing flags set?

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 23 Jun 2010 18:35:31 -0700
Message-ID: <AANLkTimZcuie-5NBKfByVOdVeN1uFavdqa0Prn9A8FLy@mail.gmail.com>
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?
Received on Wednesday, 23 June 2010 18:35:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC