Intent to Implement: Block modal dialogs inside sandboxed documents.

Skip to first unread message

Mike West

May 18, 2015, 6:27:18 AM5/18/15
to blink-dev
# Contact emails

# Spec
Just mailing list conversation at; I'm hopeful we can get it into HTML if folks think it's a reasonable addition.

# Summary
`alert()`, `confirm()`, `prompt()`, and `print()` will no longer have any affect inside sandboxed documents; they will instead synchronously return a reasonable default value (`false` for `confirm()`, and `null` for `prompt()`) without prompting the user.

# Motivation
Folks in Google's anti-malvertising team would like to be able to prevent sandboxed frames from popping up confusing, modal messages to users. Ideally, we could simply block those entirely inside sandboxed frames (as Hixie vaguely suggested in I suspect that the numbers will be low enough to make that change without much risk (sandboxing itself is hovering around 0.6% of page loads:

If the numbers are higher than I expect, we could add something like an `allow-modals` sandbox flag to support turning the feature back on.

# Compatibility Risk
Firefox: No public signals
Internet Explorer: No public signals
Safari: No public signals
Web developers: Positive

# Describe the degree of compatibility risk you believe this change poses
Browsers that support sandboxing but don't support this feature will be a bit of a problem, as there's no clear way to feature-detect sandboxing characteristics of a browser. Until such a thing exists, web developers would almost certainly need to resort to UA sniffing, which is fairly ugly.

Suggestions regarding detection possibilities are welcome. :)

# Ongoing technical constraints

# Will this feature be supported on all six Blink platforms

# OWP launch tracking bug

# Link to entry on the Chromium Dashboard

# Requesting approval to ship?


Jochen Eisinger

May 18, 2015, 6:30:21 AM5/18/15
to Mike West, blink-dev
Do we support onbeforeunload events from iframes? if yes, should we also ignore them here?

Mike West

May 18, 2015, 6:33:39 AM5/18/15
to Jochen Eisinger, Brad Hill, blink-dev
On Mon, May 18, 2015 at 12:30 PM, Jochen Eisinger <> wrote:
Do we support onbeforeunload events from iframes? if yes, should we also ignore them here?

We probably still do, and yes, we should also ignore them here.

Folks have also suggested ignoring basic auth dialogs as well (where by "ignoring", I mean "cancelling the request"). I haven't poked at that yet, but it also seems reasonable to me (+Brad Hill, who suggested this on the whatwg@ list).


Philip Jägenstedt

May 18, 2015, 8:25:34 AM5/18/15
to Mike West, Jochen Eisinger, Brad Hill, blink-dev
This sounds like a good idea. Hixie said about auth dialogs that he's "actually rather surprised that browsers still show these for iframed content." It might be worth measuring how common this is, to possibly ignore such dialogs for all iframes, sandboxed or not?


To unsubscribe from this group and stop receiving emails from it, send an email to

Brad Hill

May 18, 2015, 2:22:35 PM5/18/15
to Philip Jägenstedt, Mike West, Jochen Eisinger, blink-dev
I believe it has been attempted before (perhaps not by Blink) to block auth dialogs for all iframes and resource loads, and it broke enough things that it was backed out.  Sandboxed iframes seem like a safe place to be aggressive.

Rob Wu

May 20, 2015, 10:36:20 AM5/20/15
to Brad Hill, Philip Jägenstedt, Mike West, Jochen Eisinger, blink-dev
Please do add an opt-in like allow-modals before blocking alert/confirm/prompt by default. The current feature request makes much sense for third-party adverts, but less so for code snippet sites like JSFiddle and Stack snippets. Modal dialogs are invaluable for small code demos to show results. I expect many code snippets to fail if modals are blocked by default.

So far the replies about auth dialogs referred to frames, but keep in that the sandbox directive can also be applied to top-level frames via the sandbox directive of the Content-Security-Policy response header. So even if the current practice is that auth dialogs are already blocked in iframes, explicitly forbidding it still makes sense for top-level frames.

Kind regards,

Mike West

May 23, 2015, 3:19:09 AM5/23/15
to Rob Wu, Brad Hill, Philip Jägenstedt, Jochen Eisinger, blink-dev
FYI: landed, introducing
the new behavior and `allow-modals` to revert to status quo. It
doesn't yet block auth dialogs or onbeforeunload, but you should be
able to play with the core of the idea in an upcoming canary (behind
the experimental web platform features flag).

Reply all
Reply to author
0 new messages