Links/forms in ACF block previews navigate the iframed editor canvas on WP 7.1 (crashes editor when cross-origin)

Open
  • Is something wrong?
#1,046 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, php, wordpress
Domain
frontend

Research direction

Start with the existing "Navigation prevented for" handling in the acf-pro-blocks scripts, and look at how .acf-block-preview is rendered. Reproduce by adding a block whose render output contains an a with an external href, then clicking it in the editor. Done means clicks on non-hash a[href] and form submits inside the preview no longer navigate the canvas, while block selection still works.

Written by the indexing model from the issue text.

Description

Environment
WordPress 7.1.3 (post editor canvas always iframed, shouldIframe: true)
ACF PRO 6.8.10
Blocks registered via block.json with no block version declared (so V3 by default since 6.8.9), "acf": { "mode": "edit" }, server-rendered with render_callback

Steps to reproduce
Register an ACF block whose render output contains an (any non-# link).
Add it to a post in the block editor on WP 7.1. The preview renders, which is the V3 default.
Click the link in the preview.

Expected
Clicking a link in a block preview selects the block. It doesn’t navigate.

Actual
The click navigates the editor-canvas iframe to the link’s URL. Core’s iframe only intercepts #hash links (interceptLinkClicks in block-editor).
Same-origin link: the frontend page silently replaces the editor canvas.
Cross-origin link: the canvas window becomes cross-origin. The next time a block unmounts or re-renders, the editor crashes with “The editor has encountered an unexpected error”:

SecurityError: Failed to read a named property 'removeEventListener' from 'Window':
Blocked a frame with origin "https://example.com" from accessing a cross-origin frame.
    at wp-includes/js/dist/compose.min.js (useRefEffect cleanup)
    at $e / Bt (useMergeRefs cleanup)

A

in a preview, such as Gravity Forms, navigates the canvas on submit in the same way.

Why this is new
Before 7.1, V2 blocks disabled the iframe, and mode: edit showed the field form rather than the rendered preview. On WP 7.1 with ACF 6.8.9+, these blocks are V3 and show live, clickable server HTML inside an iframe that core doesn’t guard. ACF already prevents navigation for inline-editing elements (Navigation prevented for … in acf-pro-blocks), but not for the rest of the preview.

Suggested fix
Inside .acf-block-preview, preventDefault() capture-phase click events on non-# a[href] and submit events on forms, while leaving propagation alone so block selection still works.

Workaround we’re using
A small mu-plugin that does exactly that, via an inline script on enqueue_block_assets when is_admin() is true.
Dominant language
PHP
Stars
947
Forks
198
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AdvancedCustomFields/acf

All issues in AdvancedCustomFields/acf

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.