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 :)

[ozgursar]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11170

Environment

• WordPress: 7.0-beta2-61752-src
• PHP: 8.2.29
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
• Browser: Chrome 145.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Advanced Custom Fields 6.7.1
  • Elementor 3.34.4
  • Test Reports 1.2.1

Steps taken

1. Install Elementor latest 35.x
2. Create a blank page. Confirm editor works (as they have already patched)
3. Rollback Elementor to 3.34.4
4. Try to edit the page. View the following error in console:

Uncaught SecurityError: Failed to read a named property cross-origin frame.

5. Apply patch PR 11170
6. Try to edit the page with Elementor again
7. ✅ Patch is solving the problem

Expected result

• We expect to be able to load Elementor editor with no cross-origin errors

Screenshots/Screencast with results

Before

After
Video: ​https://files.catbox.moe/n6vtyr.mp4

[ozgursar]

Reproduction Report for the ACF WYSIWYG editor

Environment

• WordPress: 7.0-beta2-61752-src
• PHP: 8.2.29
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
• Browser: Chrome 145.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Advanced Custom Fields 6.7.1
  • Test Reports 1.2.1

Steps taken

1. Add WYSIWYG editor field to ACF field group
2. Create a blank post
3. Try typing in the editor using Visual and Text modes
4. 🐞 Bug occurs (only Text works but Visual fails - before Changeset 61844)
5. Merge Changeset 61844
6. ✅ Bug is fixed

Expected behavior

• We expect to see ACF's WYSIWYG editor works both in Visual and Text mode.

Additional Notes

• It would be nice if we can get tests from other plugins which use the WYSIWYG editor. I only tested with ACF.

Screenshots/Screencast with results

Before Changeset 61844
​https://files.catbox.moe/nu47sf.mp4

After Changeset 61844
​https://files.catbox.moe/a3dbvi.mp4

[adamsilverstein]

@MadtownLems can you give beta 3 a try to see if your issues are resolved?

[hdkothari81]

Patch Testing Report with 7.0-beta3
Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11170

Local Environment

• WordPress: 7.0-beta3
• PHP: 8.3.30 (Supports 64bit values)
• Server: nginx/1.16.0
• Database: mysqli (Server: 8.0.16 / Client: mysqlnd 8.3.30)
• Theme: Twenty Twenty-Five 1.4
• Plugins: Elementor 3.34.4

Steps Taken for Testing

• Install Elementor latest Version 3.35.6
• Create a blank page. Confirm editor works (as they have already patched)
• Rollback Elementor to 3.34.4
• Try to edit the page. View the following error in console:
• Uncaught SecurityError: Failed to read a named property cross-origin frame.
• Apply patch PR 11170
• Try to edit the page with Elementor again

Patch is solving the problem

Expected result
Load Elementor editor properly with no cross-origin errors.

Before: ​https://tinyurl.com/286lyhwu

After Video: ​https://tinyurl.com/23e7tc5d

[MadtownLems]

@MadtownLems can you give beta 3 a try to see if your issues are resolved?

Beta 3 appears to resolve my issue.

though I will say that there's significant lag in the editor area being useable upon loading the screen that was never there with 6.9.1 or any earlier version. Approximately 7 seconds after the initial page is loaded but before I can get focus into the editor.

[adamsilverstein]

though I will say that there's significant lag in the editor area being useable upon loading the screen that was never there with 6.9.1 or any earlier version. Approximately 7 seconds after the initial page is loaded but before I can get focus into the editor.

This shouldn't be related to the new client-side media handling, that code only gets loaded when you first try to upload an image. Do you see any notices in the console? can you try disabling the feature with:
add_filter( 'wp_client_side_media_processing_enabled', '__return_false', 999999 ); - does that fix the load issue for you?

[adamsilverstein]

@ozgursar as of https://core.trac.wordpress.org/changeset/61947 the Elementor issue should be resolved.

[ozgursar]

@adamsilverstein I'll test it and submit a new report now

[ozgursar]

Testing Report

I've tested against the latest trunk

Environment

• WordPress: 7.0-beta4-61919-src
• PHP: 8.2.29
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
• Browser: Opera
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Elementor 3.34.4
  • Test Reports 1.2.1
  • WP Rollback 3.0.12

Steps taken

1. Install Elementor 3.34.4
2. Create a new page
3. Confirm that editor loads properly
4. ✅ Elementor issue is resolved.

[MadtownLems]

Do you see any notices in the console?

I don't believe I did with earlier Betas, but now my console is full of:
[Violation] Permissions policy violation: unload is not allowed in this document

can you try disabling the feature

That absolutely removes the lag! (though the console [Violations] are still there)

Happy to investigate further - just let me know! Thanks for continuing to explore this.

[ozgursar]

Here's my console with Elementor 3.34.4 and Chrome, Safari, Firefox on latest trunk 7.0-beta4-61919-src

@MadtownLems which Elementor version and browser did you test with?

Chrome

Safari	Firefox

[MadtownLems]

I've been doing some timing of the Classic Editor, and while disabling client side media processing is clearly involved in the underlying issue, I found that Query Monitor being active makes the lag issue tremendously worse. More details here if interested or relevant: ​https://wordpress.org/support/topic/7-0-excessive-lag-when-loading-classic-editor/

[mukesh27]

@adamsilverstein Since the client-side media and related changes were reverted in https://core.trac.wordpress.org/changeset/62081, do we still need to keep this ticket open, or should we close it or move it to the next release milestone?

[westonruter]

I'm changing the milestone to 7.1 as this will be a companion for #64919.