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 12393 - Add "allow-popups" for iframe@sandbox
Summary: Add "allow-popups" for iframe@sandbox
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 blocker
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/Overview...
Whiteboard:
Keywords: WGDecision
: 15236 (view as bug list)
Depends on: 15837
Blocks: 15236
  Show dependency treegraph
 
Reported: 2011-03-29 07:12 UTC by Jacob Rossi [MSFT]
Modified: 2012-04-20 05:20 UTC (History)
9 users (show)

See Also:


Attachments

Description Jacob Rossi [MSFT] 2011-03-29 07:12:54 UTC
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() [1], 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.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12391
Comment 1 Adam Barth 2011-03-29 17:15:24 UTC
Makes sense to me.
Comment 2 Ian 'Hixie' Hickson 2011-06-13 22:17:10 UTC
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?
Comment 3 Ian 'Hixie' Hickson 2011-06-13 22:28:38 UTC
(by "works fine", I mean that the UA has the option of letting the user indicate that the link should work normally)
Comment 4 Ian 'Hixie' Hickson 2011-06-15 06:16:01 UTC
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.
Comment 5 Jacob Rossi [MSFT] 2011-07-12 23:44:09 UTC
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)
Comment 6 Michael[tm] Smith 2011-08-04 05:13:29 UTC
mass-move component to LC1
Comment 7 Ian 'Hixie' Hickson 2011-08-13 05:02:40 UTC
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.
Comment 8 Adrian Bateman [MSFT] 2011-10-03 23:09:10 UTC
Created ISSUE-180.
http://www.w3.org/html/wg/tracker/issues/180
Comment 9 Adam Barth 2011-11-03 00:53:05 UTC
https://bugs.webkit.org/show_bug.cgi?id=66505
Comment 10 Ian 'Hixie' Hickson 2011-11-09 23:33:22 UTC
Reopening based on existence of multiple implementations.

See also specifically this comment: https://bugs.webkit.org/show_bug.cgi?id=66505#c1
Comment 11 Adam Barth 2011-11-09 23:50:08 UTC
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.
Comment 12 Jacob Rossi [MSFT] 2011-11-10 01:22:18 UTC
(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).
Comment 13 Adam Barth 2011-11-10 01:46:31 UTC
That's slightly different from the discussion in public-web-security about CSP.  IMHO, we should tackle the CSP issues separately.
Comment 14 Jacob Rossi [MSFT] 2011-11-10 01:49:47 UTC
(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).
Comment 15 Sam Ruby 2011-11-10 19:22:11 UTC
At the present time, we have a single change proposal:

http://www.w3.org/html/wg/wiki/ChangeProposals/sandbox_allow_popups

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:

http://lists.w3.org/Archives/Public/public-html/2011Nov/0077.html
Comment 17 Ian 'Hixie' Hickson 2012-02-01 00:19:14 UTC
*** Bug 15236 has been marked as a duplicate of this bug. ***
Comment 18 Ian 'Hixie' Hickson 2012-04-17 05:04:54 UTC
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).