New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 17 users

Issue metadata

Status: Duplicate
Last visit > 30 days ago
Closed: Sep 11
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Task
Launch-Privacy: NA
Launch-Security: NA
Launch-UI: NA

Blocked on:
issue 624061

Sign in to add a comment

Issue 640057: Restrict the ability to navigate the top level context to content that is processing a user gesture, unless it is same-origin to the parent

Reported by, Aug 23 2016 Project Member

Issue description

Change description:
Content in an <iframe> can generally navigate the top level browsing context unless explicitly forbidden by the sandbox attribute (sometimes called 'framebusting'). Restrict this ability to content that is processing a user gesture, unless it is same-origin to the parent.

Framebusting was originally used by content that wanted to prevent being placed in an <iframe>. However, there are other, more specific tools to accomplish this (see section below). On the other hand, this framebusting technique is being used by malicious content to forcibly navigate the user.

Changes to API surface:
 Restrict framebusting ability to content that is processing a user gesture, unless it is same-origin to the parent.

Public standards discussion:

Support in other browsers:
Internet Explorer: no
Firefox: no
Safari: no

Comment 1 by, Aug 23 2016


Developers that wish to prevent their content from appearing in an <iframe> should use the CSP frame-ancestors directive or X-Frame-Options.

Comment 2 by, Oct 6 2016

Blockedon: 624061
Issue 624061 tracks the actual implementation work for this, right?

Comment 3 by, Oct 14 2016

Labels: -Launch-M-Target-54-Dev -Launch-M-Target-54-Beta -Launch-M-Target-54-Stable-Exp
Removing milestone while we figure out how to deal with the unexpected breakage.

Comment 4 by, Jan 4 2017

Labels: -M-54 M-56
This is currently enabled in M56 and will hit stable in a couple weeks (even though the bugs are still marked open and the chromestatus entry says in development:, right?

I'm seeing a lot of recent reports of breakage on the issue:  What do the latest UMA stats say about the compat impact?  Have we written any blog entries or done any other sort of outreach?

Comment 5 by, Jan 4 2017

Comment 6 by, Jan 11 2017

Labels: -M-56 M-57
Apologies for the delay.
Status: reverting for M56, given the breakage.
Aiming at a narrower version for M57.

Comment 7 by, Feb 12 2017

Comment 8 by, Feb 14 2017

Ownership transfer.

Comment 9 by, Feb 15 2017


Comment 10 by, Mar 28 2017

What changed with this now in M57?  M56 worked with VMware vSphere 6.5 Enhanced Authentication Plugin, now it's broken ... tried disabling Framebusting flag in M57 but doesn't help.  Error I see from the vCenter's login page in Chrome Console (censored hostname, but its a different host than the website serving up the page):

Uncaught DOMException: Failed to execute 'assign' on 'Location': Blocked a frame with origin "https://XXX" from accessing a cross-origin frame.
    at ApiConnection.__startProtocolServer__ (https://XXX/websso/resources/js/assets/csd_api_connection.js:212:23)
    at ApiConnection.__callStartProtocolServer__ (https://XXX/websso/resources/js/assets/csd_api_connection.js:194:12)
    at ApiConnection.__on_lookup_connected__ (https://XXX/websso/resources/js/assets/csd_api_connection.js:180:15)
    at WebSocket.socket.onopen (https://XXX/websso/resources/js/assets/csd_api_connection.js:124:16)

Comment 11 by, Mar 28 2017

@arrons, We've reverted this change in Chrome 57 (See, and it seems the breakage you mentioned is unrelated to this change.

Comment 12 by, Mar 28 2017


Comment 13 by, Aug 7 2017

Hi, today I saw a warning about this in the Chrome console. Enabling the feature in labs it's breaking our authentication system. Is this moving forward? I'm also following the issue in GitHub and I did not see any movement recently.

Comment 14 by, Aug 7 2017

We're hooking it up to the same UI as we use for popup-blocking so that, if there is content that can't be updated, users can still get to the next page.  Once we get that completed, we're planning to try shipping it again.

Unfortunately, that won't help with lab-testing cases.

rbyers/dknox: Any thoughts on what we should do when a behavior makes sense except in the lab? What's our solution for other scenarios like this?

Comment 15 by, Aug 8 2017

Thank you, Ojan.

Is there any ETA?

Comment 16 by, Sep 12 2017

Labels: migrated-launch-owp Type-Task
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.

We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.

For more details see here:

For any questions, please contact owencm, sshruthi, larforge

Comment 17 by, May 8 2018


Comment 18 by, May 16 2018

The blog entry for this says it was happening in 64, and chromestatus says 65, but it doesn't look like it's enabled yet (it's still off by default in the code, I can't find an experiment referring to it, and testing it seems like it's still permitted). What's the current status of this? We're potentially interested in enabling this or something similar for WebView and want to know what the current status for Chrome is.

Comment 19 by, May 16 2018


Comment 20 by, Sep 11

Mergedinto: 780018
Status: Duplicate (was: Assigned)

Sign in to add a comment