Editor: leave undo to the browser in fields that handle their own undo

[ellatrix]

What?

Fixes #80541. Fixes #38731. Fixes the link dialog and "Edit as HTML" problems reported in this comment on #44238; the scroll jump that issue originally reports could not be reproduced and remains open. Cmd+Z inside the link dialog, a block's "Edit as HTML" view, the Custom HTML block's editing dialog, or a classic meta box field no longer rewinds the editor history. The browser's own undo acts on the field instead.

Why?

The undo and redo shortcuts are global, so they fire from any focused element. Fields whose text is not in the editor history (the link dialog commits on Apply, the HTML view on blur) cannot be undone by it, so undo there rewound an earlier, unrelated change: the dialog closed, other blocks lost content, and redo could not always restore it.

How?

An element that relies on the browser's own undo registers itself through a private useNativeUndo ref hook, and the global handlers leave the shortcut alone within it (checked via the paired usesNativeUndo( event )). The registry is a module-private WeakSet, deliberately invisible in the DOM so the mechanism is not adoptable as a de facto public API and can change later. The link dialog, the "Edit as HTML" textarea, the Custom HTML block's editing dialog, and the meta box areas register. Meta box contents are plugin-rendered classic form fields whose values are never part of the editor history, so the whole area registers as one. Since canvas keyboard events are re-dispatched on the iframe element, the real target is resolved through the frame's focused element. Everything else is unchanged, including plugin fields synced to block attributes.

Alternatives considered:

• Attaching the handlers to editor surfaces (canvas, list view, header) or one root node with popovers mounted outside: the surface is a proxy for the real criterion (is this text in the editor history?) and misses in both directions. It is overinclusive (the HTML editing textarea lives in the canvas, so it stays hijacked) and underinclusive (plugin panels whose fields sync to block attributes lose undo).
• stopPropagation() in the field: every such field must know an ancestor is listening, and it silences all other listeners.
• event.defaultPrevented as the signal: unavailable, because rich text prevents the default of these keys to suppress the browser's content editable undo, expecting the editor history to take over.
• Skipping input/textarea targets: changes undo in fields synced per keystroke to block attributes (e.g. PlainText blocks), where editor undo is correct.
• A data- attribute as the marker: works identically, but a readable attribute is a public API the moment it ships; hiding it behind the hook keeps the mechanism replaceable.

This deliberately does not close #18755, the umbrella issue. Remaining for that:

• Register the remaining core local-state fields (block rename modal, create-pattern modal, inline image size popover, and similar).
• Consider a blanket rule for modals: registering the Modal component covers them all, but requires moving the registry below block-editor (e.g. @wordpress/compose) so components can use it.
• Document that fields synced to block attributes or post fields intentionally keep editor undo.
• A public opt-in for plugin fields; the mechanism is private until proven.

Testing Instructions

1. Select a word, press Cmd+K, type in the URL field, press Cmd+Z: the typing reverts, the dialog stays open, the canvas is untouched.
2. Switch a block to Edit as HTML, type in the textarea, press Cmd+Z: the typing reverts, other blocks stay intact, Cmd+Shift+Z restores it.

Covered by four regression tests (three in the undo suite, one in the meta boxes suite); all fail on trunk. The Custom HTML one asserts redo restores the typing, which distinguishes the browser's own undo from the editor history remounting the dialog: the remount resets the field to the same committed value, but destroys the browser's redo stack with it.

Use of AI Tools

Written with Claude Code, reviewed and tested by me.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @Michael-Z-Freeman, @maksymmamontov, @smerriman, @himanshu-mahendra-jain, @landwire.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: Michael-Z-Freeman, maksymmamontov, smerriman, himanshu-mahendra-jain, landwire.

Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: scruffian <scruffian@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: paaljoachim <paaljoachim@git.wordpress.org>
Co-authored-by: eliot-akira <miyarakira@git.wordpress.org>
Co-authored-by: stokesman <presstoke@git.wordpress.org>
Co-authored-by: Thelmachido <thelmachido@git.wordpress.org>
Co-authored-by: ndiego <ndiego@git.wordpress.org>
Co-authored-by: sybrew <cybr@git.wordpress.org>
Co-authored-by: rmorse <codeamp@git.wordpress.org>
Co-authored-by: rilwis <rilwis@git.wordpress.org>
Co-authored-by: cbirdsong <cbirdsong@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: +282 B (0%)

Total Size: 7.76 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	428 kB	+124 B (+0.03%)
build/scripts/block-library/index.min.js	356 kB	+34 B (+0.01%)
build/scripts/customize-widgets/index.min.js	14.6 kB	+31 B (+0.21%)
build/scripts/edit-post/index.min.js	52 kB	+38 B (+0.07%)
build/scripts/edit-widgets/index.min.js	22.3 kB	+48 B (+0.22%)
build/scripts/editor/index.min.js	500 kB	+7 B (0%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in f719f0f.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/30384356206
📝 Reported issues:

• [Flaky Test] should paste block styles using keyboard #78759 in /test/e2e/specs/editor/various/list-view.spec.js

[Mamaduka]

We could also resolve #80541 and #38731 with the same method on our end. #18755 - here, I don't think we should apply the attribute globally, but let consumers opt out.

Also, what do you think about using a more general name? Something like data-native-undo="true"?

[scruffian]

Should we also run the E2E tests in Webkit and Firefox for better coverage?

[scruffian]

Should we add CHANGELOG entries in block-editor, block-library, editor, and edit-post?

[ellatrix]

For change log, there's nothing affecting package consumers, it's all internal? The whole thing is opt-in.

Not sure if webkit and Firefox could behave differently here, but I suppose we could.

[scruffian]

This fixes #80541 and the code looks good. I didn't read the tests in full yet.

[t-hamano]

I'm considering whether to backport this PR to 7.1 Beta 4. Should we also add the usesNativeUndo guard to the shortcuts for edit-widgets and customize-widgets? Otherwise, I feel there will be a difference in the behavior of the undo shortcuts.

[t-hamano]

Should we also add the usesNativeUndo guard to the shortcuts for edit-widgets and customize-widgets? Otherwise, I feel there will be a difference in the behavior of the undo

This has been addressed in df3b53c. This should ensure consistent undo behavior across all editors.

Before

before.mp4

After

after.mp4

[t-hamano]

I'm going to merge this and backport it to 7.1.

[github-actions]

I just cherry-picked this PR to the wp/7.1 branch to get it included in the next release: f65b5d5

[ellatrix]

Thanks Aki!

[Mamaduka]

@ellatrix, discovered a small issue when trying to opt out of editor undo for the RichText field. Below is the gist form debugging session.

---

An empty editable renders as [#text(""), #text("\uFEFF"), <span data-rich-text-placeholder>] (to-tree.js:323-338). Chrome types into the \uFEFF node. Rich text then has to strip that padding, and applyValue does it with replaceChild.

Chrome's pending typing command points at that text node. Replacing it detaches the node, so undoing the first character becomes a no-op. Chars 2+ reference the surviving node and undo fine. Hence, the first character is stuck.

[one-sz]

I'm not sure if this issue is back again.

When editing a post/page using the WordPress Block Editor, the global keyboard shortcut handling in @wordpress/compose prevents the native Ctrl+Z / Ctrl+Y behavior in textarea and text input elements that are not part of the Block Editor.

This also affects ACF fields rendered as <textarea>, but the issue can be reproduced without ACF or any third-party plugin.

Steps to reproduce

1. Open a post/page in the WordPress Block Editor.
2. Open the browser console.
3. Create a regular textarea:

const test = document.createElement('textarea');
test.style.position = 'fixed';
test.style.top = '20px';
test.style.left = '20px';
test.style.zIndex = '99999';
document.body.appendChild(test);
test.focus();

4. Type some text into the textarea.
5. Press Ctrl+Z.

Expected result:
The native browser undo operation should undo the last change in the textarea.

Actual result:
Nothing happens.

However, right-clicking inside the textarea and selecting "Undo" works correctly.

The same happens with Ctrl+Y for redo.

Additional information

The issue is not caused by preventDefault() being called directly by the test listener. The relevant keyboard handler comes from:

/wp-includes/js/dist/compose.min.js

The registered document keydown handler contains:

function ze(v){
    typeof v.which!="number"&&(v.which=v.keyCode);
    var E=m(v);
    if(E){
        if(v.type=="keyup"&&M===E){
            M=!1;
            return
        }
        c.handleKey(E,S(v),v)
    }
}

The handler intercepts Ctrl+Z even when the event target is a normal textarea outside the Block Editor.

Interestingly, Ctrl+Z works normally inside native Gutenberg blocks, e.g. a standard Paragraph block, because Gutenberg handles the undo operation itself.

Workaround

The following capture-phase listener restores native undo/redo behavior for textareas and text inputs:

document.addEventListener('keydown', function (event) {
    if (!event.ctrlKey) {
        return;
    }
    if (!['z', 'y'].includes(event.key.toLowerCase())) {
        return;
    }
    const target = event.target;
    if (
        target instanceof HTMLTextAreaElement ||
        (
            target instanceof HTMLInputElement &&
            !['checkbox', 'radio', 'button', 'submit', 'reset'].includes(target.type)
        )
    ) {
        event.stopImmediatePropagation();
    }
}, true);

This allows the browser's native Ctrl+Z/Ctrl+Y behavior to work again in textarea/input elements while leaving Gutenberg's undo shortcuts working normally inside Gutenberg blocks.

Expected behavior

The global Block Editor keyboard shortcut handler should not prevent native Ctrl+Z/Ctrl+Y behavior for standard textarea and text input elements that are outside the Gutenberg editing surface.

Environment

WordPress: 7.1.2
Browser: Google Chrome 154
OS: Windows

The issue was reproduced in a WordPress development environment with all plugins disabled, and also using a dynamically-created plain textarea, so it does not appear to be specific to ACF or another third-party plugin.