Fix: Edit block as HTML regression from since WP 7.0

[hbhalodia]

What?

Closes #82683

Applies the parser's built-in validation fixes on the "Edit as HTML" path, so an id, class or aria-label typed by hand no longer sends the block into recovery.

Why?

Regression from #70993, which changed how anchors are saved. That PR shipped applyBuiltInValidationFixes() to recover these attributes from markup, but the Edit as HTML path never reaches it.

block-html.jsx runs its own getBlockAttributes() + validateBlock(), and getBlockAttributes() only sources what the block's save output declares. A hand-typed id is invisible to it, so it never becomes the anchor attribute and validation fails.

How?

• packages/blocks: expose applyBuiltInValidationFixes through the existing locked privateApis.
• packages/block-editor: in BlockHTML's onChange, apply the fixes when validation fails and re-validate, the same sequence parser/index.ts uses.

This passes the same shape the parser does (originalContent = the raw markup), so both paths now recover global attributes identically.

Covers class and aria-label as well as anchor, same code path, same gap.

Testing Instructions

1. Add a Heading block with some text.
2. Block options (⋮) → Edit as HTML.
3. Add an id="test" attribute to the heading.
4. Switch back to block view.

Before: the block drops into recovery mode.
After: the block validates, and the inspector's Advanced → HTML anchor field shows test.

Testing Instructions for Keyboard

N/A

Screenshots or screencast

The issue's screencast shows the before state: https://d.pr/v/BTYKGl

After

Screen.Recording.2026-09-14.at.4.06.10.PM.mov

Use of AI Tools

• Claude Code, Opus 5.
• Used for diagnosis, implementation, PR description.
• The fix was tested and reviewed by me.

[github-actions]

🤖 PR meta 🤖

🏷️ Labels

This pull request needs exactly one label indicating its type, and has 2.

• Required: any label starting with [Type].
• Found: [Type] Bug, [Type] Regression.

Read more about Type labels in Gutenberg. If you cannot add labels yourself, a reviewer can do it for you.

[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.

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

Co-authored-by: hbhalodia <hbhalodia@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org>
Co-authored-by: tommusrhodus <tommusrhodus@git.wordpress.org>

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

[t-hamano]

Thanks for the PR. How about only applying applyBuiltInValidationFixes when the block validation fails? Something like this:

		const content = html ? html : getSaveContent( blockType, attributes );

		const updatedBlock = {
			...block,
			attributes,
			originalContent: content,
		};
		const [ isValid ] = html ? validateBlock( updatedBlock ) : [ true ];

		// `getBlockAttributes` only sources what the save output declares,
		// so recover hand-typed `id`/`class`/`aria-label` for invalid blocks.
		const fixedBlock = isValid
			? updatedBlock
			: applyBuiltInValidationFixes( updatedBlock, blockType );

		updateBlock( clientId, {
			attributes: fixedBlock.attributes,
			originalContent: content,
			isValid: isValid || validateBlock( fixedBlock )[ 0 ],
		} );

[hbhalodia]

Thanks for the PR. How about only applying applyBuiltInValidationFixes when the block validation fails? Something like this:

		const content = html ? html : getSaveContent( blockType, attributes );

		const updatedBlock = {
			...block,
			attributes,
			originalContent: content,
		};
		const [ isValid ] = html ? validateBlock( updatedBlock ) : [ true ];

		// `getBlockAttributes` only sources what the save output declares,
		// so recover hand-typed `id`/`class`/`aria-label` for invalid blocks.
		const fixedBlock = isValid
			? updatedBlock
			: applyBuiltInValidationFixes( updatedBlock, blockType );

		updateBlock( clientId, {
			attributes: fixedBlock.attributes,
			originalContent: content,
			isValid: isValid || validateBlock( fixedBlock )[ 0 ],
		} );

Thanks, Let me check on this and confirm.

[hbhalodia]

Thanks, I have used that only when the block is invalid. It also mirrors the implmentation here in the parser

gutenberg/packages/blocks/src/api/parser/index.ts

Line 127 in db62c92

function applyBlockValidation(