Expanded Editor silently ignores Done, Esc and click-away while the block preview re-fetches

[charlie-george-1989]

Describe the bug

While the Expanded Editor is open, changing a field queues a block preview re-fetch. For as long as that fetch is in flight, all three ways of closing the panel stop working at the same time: the Done button, the Escape key, and clicking outside it. The panel also sets isDismissible: false, so there is no close icon to fall back on. Nothing indicates the panel is busy (Done has no spinner and no disabled styling), so it reads as frozen rather than working. On our blocks the window lasts between 0.4 and 4.5 seconds depending on how heavy the block's preview is.

To Reproduce

Steps to reproduce the behavior:

1. Register an ACF v3 block from block.json with a wysiwyg field (any block whose preview takes a moment to render server-side).
2. Add the block to a page and open the Expanded Editor from the pencil in the block toolbar.
3. Type into the wysiwyg, which queues a preview re-fetch.
4. Immediately click Done - nothing happens.
5. Press Escape - nothing happens.
6. Click outside the panel - nothing happens.
7. All three start working the moment the fetch resolves.

Expected behavior

At least one exit should work at all times. Either Done stays enabled and closes the panel, since the field values are already in the store by that point, or the busy state is made visible with a spinner or a genuinely disabled-looking button. The silent dropping of Escape and click-away is the most confusing part, as neither gives the editor any feedback at all.

Screenshots or Video

[attach a screen recording of clicking Done repeatedly with nothing happening]

Code

block.json:

{
    "name": "acf/repro-expanded-editor",
    "title": "Repro Expanded Editor",
    "description": "Minimal block to reproduce the Expanded Editor close guard.",
    "category": "widgets",
    "icon": "edit",
    "acf": {
        "blockVersion": 3,
        "mode": "preview",
        "renderTemplate": "render.php"
    },
    "supports": { "anchor": true }
}

render.php:

<div class="repro-expanded-editor">
    <?php the_field( 'body' ); ?>
</div>

Field group export:

{
    "key": "group_6b0a1c2d3e4f5",
    "title": "Repro Expanded Editor",
    "fields": [
        {
            "key": "field_6b0a1c2d3e4f6",
            "label": "Body",
            "name": "body",
            "type": "wysiwyg",
            "tabs": "visual",
            "media_upload": 0
        }
    ],
    "location": [
        [
            { "param": "block", "operator": "==", "value": "acf/repro-expanded-editor" }
        ]
    ],
    "active": true
}

Version Information:

• WordPress Version 7.1
• PHP Version 8.2.16
• ACF Version ACF PRO 6.8.7
• Browser [add yours]

Additional context

The relevant code is the Expanded Editor modal in assets/build/js/pro/acf-pro-blocks.min.js. Reading the minified bundle, four things are keyed to the same isFetchingBlock flag:

• onRequestClose returns early while fetching with no validation errors, so click-away is dropped
• the Done button's disabled prop is isFetchingBlock && !validationErrors
• shouldCloseOnEsc is !isFetchingBlock || validationErrors
• isDismissible is false

So for the duration of a fetch the modal has no exit at all. Guarding against closing mid-fetch is reasonable in itself; the problem is that every route is gated on one flag with no user-facing feedback.

In practice editors read it as a hang, click Done several times, and some reload the page and lose the edit. Our production blocks also set hideFieldsInSidebar and expandedEditorButtons: ["toolbar"], which is where we first hit this - the minimal repro above leaves them out, since the guards themselves don't reference either option.

[johnstonphilip]

@charlie-george-1989 Thank you for the feedback. We will work on improving the UI/UX to show the user that work is in-progress more clearly.

[charlie-george-1989]

@charlie-george-1989 Thank you for the feedback. We will work on improving the UI/UX to show the user that work is in-progress more clearly.

Hi John, thank you for your reply. I’m not sure what you mean. Are you saying the expanded editor is not yet fully compatible with ACF blocks? Or are you saying you’ll add some kind of overlay to warn the user the editor is WIP?

[johnstonphilip]

@charlie-george-1989 if I understood correctly, you are requesting that the "work-in-progress" happening in the background be more obvious, and that the reason the button is disabled also be more obvious to the user.

Right now the button just goes into this state (spinning lines behind the word "done")

But you would like that to be much more obvious, that it's disabled and "work-in-progress" is blocking it from being clicked (disabled).

Is that correct?