credentialless iframe incompatible with some browsers and cross-origin policies

[amykamala]

After the 7.0 Beta 1 launch, Core received ​this report of a NS_ERROR_DOM_COEP_FAILED error in Firefox related to the iframed post editor.

Firefox currently does not support credentialless iframes and has an ​open bug about it -- the result is some users may encounter that error and be unable to edit if using Firefox.

Today just before the Beta 2 launch I received an additional report from Elementor, stating that they are encountering errors with credentialless iframes at scale - which could potentially break 4 million or more websites for WP users that use Elementor, upon upgrading to 7.0.

A workaround is being implemented in Elementor version 3.35+, but folks using older versions of the plugin, (3.34 and below) are likely to have a broken editor upon updating to 7.0. So backwards compatibility for Elementor users is not in place once upgraded to WP 7.0. Below are the details of the report -

Steps to reproduce:

1. Install WordPress 7.0-beta1 (or nightly: wp core update ​https://wordpress.org/nightly-builds/wordpress-latest.zip)
2. Install and activate Elementor
3. Open any page in the Elementor editor
4. Editor fails to load; console shows SecurityError

Quick analysis:

WordPress 7.0-beta1 introduces cross-origin isolation headers on all admin pages:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: credentialless

These headers are not present on frontend pages, including the Elementor preview iframe (/?p=X&elementor-preview=1). When a parent document sets Cross-Origin-Embedder-Policy: credentialless and an embedded iframe does not cooperate with this policy, the browser treats the iframe as cross-origin, even when both share the same origin. This blocks all contentWindow property access from the parent to the iframe.

The Elementor editor relies on accessing contentWindow.elementorFrontend in Editor.onPreviewLoaded() (assets/dev/js/editor/editor-base.js:1266-1268). With WP 7.0, this throws:

Uncaught SecurityError: Failed to read a named property 'elementorFrontend' from 'Window':Blocked a frame with origin "​http://..." from accessing a cross-origin frame.

The editor fails to initialize entirely.

[westonruter]

This is a workaround that has worked:

<?php
add_filter( 'wp_client_side_media_processing_enabled', function( $enabled ) {
    if ( str_contains( $_SERVER['HTTP_USER_AGENT'] ?? '', 'Firefox' ) ) {
        $enabled = false;
    }
    return $enabled;
} );

It seems the feature should be disabled in Firefox by default?

Trac ticket: https://core.trac.wordpress.org/ticket/64740

## Use of AI Tools

n/a

[amykamala]

ACF is also affected by this (credentialless attribute compatibility). They shared this in #core:

"mattgrshaw  [4:46 PM]
Hello from the ACF team!

We're still looking into this, but it looks like the ACF WYSIWYG/TinyMCE issue is caused by the credentialless attribute introduced in this PR:
​https://github.com/wordpress/gutenberg/pull/74418

We've found a workaround on our side, but it's definitely a hack we'd rather avoid shipping. We're also wondering if same-origin iframes (like TinyMCE's) without an external src need the credentialless attribute applied. Happy to discuss further or open a GitHub issue if that would help."

​https://wordpress.slack.com/archives/C02RQBWTW/p1772153184010619?thread_ts=1771603791.270799&cid=C02RQBWTW

This PR would fix the issue in Firefox, but it doesn't address issues in Chromium.

[amykamala]

Another report in #core shared during bug scrub on the 26th

​https://wordpress.slack.com/archives/C02RQBWTW/p1772128205534569

"WPCasa  [9:50 AM]
I am unable to work with WP 7.0 in Playground and with Firefox. It is not possible to add a new page, open the website editor, or edit styles. The message "Blocked page: Your organization has blocked access to this page or website" always appears. I have read that there was a chat about this topic previously, but I cannot find a ticket for this issue (in my opinion, it is a blocker). Did I overlook the ticket, or should I open a new one?"

[mattshaw]

Just chiming in here with steps to replicate with ACF (though this will likely affect other plugins using the TinyMCE editor in metaboxes in the Gutenberg post editor as well).

To reproduce:

1. Have a fresh WordPress install running WordPress 7.0-beta2 and running the default Twenty Twenty-Five theme
2. Install ACF and create a field group with a WYSIWYG field, leaving all other settings at their defaults
3. Create a new post and try to interact with the WYSIWYG field in the metabox at the bottom of the page. With the credentialless attribute applied to the TinyMCE iframe, the TinyMCE "Visual" editor will not be editable.

[adamsilverstein]

I am attempting to address all of the reported issues in ​https://github.com/WordPress/gutenberg/pull/75991 by switching from iframe credentialless to using Document-Isolation-Policy for Chrome.

Client Side Media should be disabled by default for Safari and Firefox as of Beta 2, see ​https://github.com/WordPress/gutenberg/pull/75863 - however we may need to extend this to the headers we are adding if they still cause an issue. The PR does that (but so far isn't fixing the issue).

[adamsilverstein]

@mattshaw can you give ​https://github.com/WordPress/gutenberg/pull/75991 a test to see if it resolved your issue? it eliminates the need for credentialless by using a newer browser feature (Document-Isolation-Policy)

[adamsilverstein]

@amykamala

I have disabled the headers and credentialless application for non GB editors based on the action not being edit (action=elementor for elementor) in ​https://github.com/WordPress/gutenberg/pull/75991.

This should disable the feature for now in Elementor, can you double check that everything works as expected - especially media uploads? Elementor loaded in my local after this change without the previous error.

[soyebsalar01]

Tested on WordPress 7.0-beta in Firefox with Elementor.

Before applying the patch, the editor stuck on loading and console showed a cross-origin frame SecurityError.

After applying the patch, the editor load correctly and no cross-origin errors appear in the console.

Patch resolves the issue in Firefox in my testing.

[adamsilverstein]

Thanks for testing @soyebsalar01. This PR removes some headers Firefox no longer needs since we disabled the feature there.

I also verified this fixed the issue with ACF WISYWIG editor as well as Elementor.

[louiswol94]

Hi everyone,

Louis here from Elementor. Thank you all for the amazing work you are doing!

I would just like to confirm that we tested @adamsilverstein 's PR and can confirm it is working as expected.

Kind regards

[MadtownLems]

I've spent the last day troubleshooting why the Classic Editor wasn't working for us on 7.0-beta-2, and my journey eventually brought me here 😅

My situation:
Testing 7.0-beta-2 - works fine on LocalWP, but noticed the Classic Editor didn't work properly when run from our server (same server that we've been running WP on successfully for years). On first load (Add Post), one cannot get their cursor into the editor. Once you Save Draft, or edit an existing Post, it works fine. (Zero plugins, core theme, etc)
Note: We enforce the Classic Editor (on some sites) with a very basic one-liner:
add_filter('use_block_editor_for_post', 'return_false');

Eventually, I traced it down to these cross-origin policies. Adding a /wp-admin/.htaccess file with this resolves my issue

<IfModule mod_headers.c>

Header always unset Cross-Origin-Embedder-Policy
Header always unset Cross-Origin-Opener-Policy
Header always set Cross-Origin-Embedder-Policy "unsafe-none"
Header always set Cross-Origin-Opener-Policy "same-origin-allow-popups"

</IfModule>

The suggested patch - as is - did NOT resolve my issue, as I'm using Chrome. However, simply returning false from that filter DOES resolve my issue.

Happy to do further research/testing or answer any additional questions :)