Undo: typing something after fresh post load cannot be undone

[ellatrix]

Describe the bug

To reproduce

1. Load a post, e.g. the demo content.
2. Type something in a paragraph block, e.g. "test".
3. Try to undo it with the button.
4. The button becomes disabled, but the post content remains unchanged.

Expected behavior

I expect the post content to be restored as it was when loaded.

Screenshots

[ellatrix]

Not sure if this is a regression, but I'm pretty sure this worked correctly before. Looks like it is.

[aduth]

I reproduced in master and also in Gutenberg 5.4.0 , but it appears as though it had been working correctly in WordPress 5.1.x .

From some initial debugging, it appears related to the block editor module in #13088, specifically around how it keeps the blocks value in sync between the two stores editor and block-editor. When pressing Undo, the state is updated to the expected values in editor store, but it's never synced back to block-editor.

In testing, when pressing Undo it appears to get stuck in the first of the condition steps of:

gutenberg/packages/block-editor/src/components/provider/index.js

Lines 38 to 43 in 0d26bba

	if ( this.isSyncingOutcomingValue ) {
	this.isSyncingOutcomingValue = false;
	} else if ( value !== prevProps.value ) {
	this.isSyncingIncomingValue = true;
	resetBlocks( value );
	}

Meaning:

• The new blocks value is never reflected in the block editor (resetBlocks is not called)
• this.isSyncingOutcomingValue is being unset later than we expect
  • My expectation is that it should be unset immediately after calling onChange or onInput, not after the multi-second delay it took me before pressing the Undo button. This implies that it's waiting until some next state change before taking effect.

[aduth]

The issue also occurs only if multiple inputs occur within the paragraph, not just a single keypress, which would seem to indicate it could be related to undo history state merging.

[aduth]

I further suspect it is related to the delayed explicit creation of an undo level from RichText, where this is considered in addition to an actual change in blocks value when syncing the value from block editor.

gutenberg/packages/block-editor/src/components/provider/index.js

Lines 97 to 111 in 0d26bba

	if (
	newBlocks !== blocks ||
	// This happens when a previous input is explicitely marked as persistent.
	( newIsPersistent && ! isPersistent )
	) {
	blocks = newBlocks;
	isPersistent = newIsPersistent;
	this.isSyncingOutcomingValue = true;
	if ( isPersistent ) {
	onChange( blocks );
	} else {
	onInput( blocks );
	}
	}

Since this.isSyncingOutcomingValue could potentially be set without the blocks value actually changing, it means that the logic for unsetting it in componentDidUpdate will likely not be run immediately since there is no change in props value.

A simple solution here may be to only set this.isSyncingOutcomingValue = true; if the blocks value changes, since the purpose of the value is in avoiding to resetBlocks when it occurs as a result of a change from the block editor.

I'll give it a try.