Alternatives:

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

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

Removing milestone while we figure out how to deal with the unexpected breakage.

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: https://www.chromestatus.com/features/5851021045661696), right?

I'm seeing a lot of recent reports of breakage on the issue: https://github.com/WICG/interventions/issues/16.  What do the latest UMA stats say about the compat impact?  Have we written any blog entries or done any other sort of outreach?

For context, the intent to ship discussion was here: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Xi8-y4ySjA4/Eb1sBWH8BQAJ

Apologies for the delay.
Status: reverting for M56, given the breakage.
Aiming at a narrower version for M57.

see b/34983924

Ownership transfer.

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)

@arrons, We've reverted this change in Chrome 57 (See https://github.com/WICG/interventions/issues/16#issuecomment-288801751), and it seems the breakage you mentioned is unrelated to this change.

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.

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?

Thank you, Ojan.

Is there any ETA?

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: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit

For any questions, please contact owencm, sshruthi, larforge

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.