Fix: Unexpected block validation error with unescaped ampersands.

[fastlinemedia]

Description

This is a first pass at fixing issue #12448.

The issue appears to be that block.attributes is passed escaped to isValidBlockContent using parseWithAttributeSchema while innerHTML is not escaped. This results in the valid check returning false even though nothing has actually changed.

How has this been tested?

Please see issue #12448 for details on testing.

[talldan]

Hi @fastlinemedia - Thanks for looking into this and working on a fix.

I think that from a user experience point of view, the one issue I have with this approach is that the user's content ends up being silently changed (even if it might be for better). That particularly happens in the case where the user might have invalid markup (like the case described in #13158). Any thoughts on how that might be addressed? (edit: I realise that was already the case before this PR, so ignore this comment!)

[aduth]

This will degrade performance significantly for longer posts, given the implementation of parseWithAttributeSchema.

[aduth]

If I understand the issue correctly, it seems like something which can be built in to the validation logic itself, since there's already a "normalization" procedure there to handle these sorts of situations where two types of texts should be treated as equivalent.

gutenberg/packages/blocks/src/api/validation.js

Lines 144 to 154 in 1748145

	/**
	* Array of functions which receive a text string on which to apply normalizing
	* behavior for consideration in text token equivalence, carefully ordered from
	* least-to-most expensive operations.
	*
	* @type {Array}
	*/
	const TEXT_NORMALIZATIONS = [
	identity,
	getTextWithCollapsedWhitespace,
	];

[aduth]

Previously: #11771

[aduth]

See alternative fix: #13512

[fastlinemedia]

Thanks @aduth and @talldan! That all makes sense. I really appreciate the help with this one. I'll close in favor of #13512.