There's currently no way for a sandboxed iframe to generate popups (which for some mashup scenarios, may be valid). We should add an "allow-popups" token for the sandbox attribute.
When set, window.open(), showModalDialog() , and links with target=_blank would be allowed. However, the newly created browsing contexts should inherit the sandbox restrictions of the context from which the popup was created.
Makes sense to me.
target="_blank" works fine, as far as I can tell, even in sandboxed iframes.
What's the use case for sandbox content being allowed to script pop-ups?
(by "works fine", I mean that the UA has the option of letting the user indicate that the link should work normally)
Without a clear understanding of the use cases, I think we're better off delaying this until this feature is better understood. In particular, the idea of having sandboxing flags on a top-level browsing context is somewhat scary.
Marking LATER for now; I'll reopen this when sandbox="" is more widely implemented.
Reopening this as sandbox="" is now more widely implemented (IE10 Platform Preview 2). :-)
IE10 PPB2 includes a vendor prefixed implementation of allow-popups. Here's one good use case:
A site sandboxes a maps widget. The maps widget offers options to launch a popup for a larger map or for finding directions.
By default in both Chrome and IE10, the popups are blocked. Using allow-popups enables the control to work as expected while still sandboxing the widget in the other ways.
Demo: http://ie.microsoft.com/testdrive/HTML5/sandbox/Default.html (click Controlling Popups)
mass-move component to LC1
IE10 hasn't even shipped, so that really doesn't count as "widely implemented" yet! I meant when it's widely-enough implemented that people are able to rely on it at all.
The experience with IE10 will be helpful in informing the specification. It'll be interesting to see how people use the feature.
Reopening based on existence of multiple implementations.
See also specifically this comment: https://bugs.webkit.org/show_bug.cgi?id=66505#c1
Another subtly is whether the sandbox flags get applied to the main frame of the popup or to the document (i.e., whether subsequent documents that inhabit the frame are sandboxed). WebKit applies the sandbox bits to the frame so that future documents in that frame also are sandboxed.
If the user navigates via the browser's location bar, the bits a cleared because the new document is loaded into a "new" frame.
(In reply to comment #11)
> Another subtly is whether the sandbox flags get applied to the main frame of
> the popup or to the document (i.e., whether subsequent documents that inhabit
> the frame are sandboxed). WebKit applies the sandbox bits to the frame so that
> future documents in that frame also are sandboxed.
> If the user navigates via the browser's location bar, the bits a cleared
> because the new document is loaded into a "new" frame.
IE10 follows a similar design. Navigations from within the page with CSP (clicking a link, window.location=foo, window.open(foo,"_self"), etc.) persist the restrictions. However, if the user navigates with the address bar then the sandbox bits are cleared.
Child frames within a document with a CSP sandbox header also inherit those restrictions (in the same way a child frame of a sandboxed iframe inherit sandbox flags per HTML5).
That's slightly different from the discussion in public-web-security about CSP. IMHO, we should tackle the CSP issues separately.
(In reply to comment #13)
> That's slightly different from the discussion in public-web-security about CSP.
> IMHO, we should tackle the CSP issues separately.
Ack. I was still thinking about CSP when I wrote this--didn't mean to mix. My comment also applies to popups created from a sandboxed frame:
The popup inherits the same restrictions. Navigations from within the page continue to have the sandbox restrictions. User navigations from the address bar clear the restrictions.
Child frames within the popups also inherit the sandbox restrictions (same way as child frames in the sandbox iframe).
At the present time, we have a single change proposal:
This change proposal is not to be applied until and unless we determine that there is consensus on this proposal.
If anyone in the working group disagrees with that proposal, we request that they submit an Alternate or Counter Proposal by December 10, 2011:
*** Bug 15236 has been marked as a duplicate of this bug. ***
Done (with some minor tweaks — one based on discussions with Adrian on IM, to still allow UAs to have UI that overrides sandboxing; some minor tweaks to how the speccing works to work in the framework we have post-CSP refactoring; and a tweak to handle one place that the CP forgot to fix, namely the navigation algorithm).