Undo / Redo unreliable with the post title

[afercia]

Splitting this out from #5685 (comment) / #10650

#10650 improved a lot the Undo / Redo behavior with regards to RichText.

However, seems the post title is not always included in the undo / redo history. Following the steps listed on #5685 (comment) there are still cases where the post title is not restored or not removed when undoing / redoing.

Quoting @iseulde:

I think only blocks are included in the history reducers.

I haven't followed this part of the development but seems to me it's something worth investigating.

[aduth]

Not sure it's entirely related to what's seen, but it occurs to me that since the title field is "controlled" by editor state, it should have its default Undo/Redo behavior absorbed by the application handler.

Related discussion: #10650 (comment)

[designsimply]

Tested and confirmed that undo did not affect title changes and that redo took more clicks than expacted using WordPress 4.9.8 and Gutenberg 4.5.1 using Firefox 63.0.1 on macOS 10.13.6. (52s)

[xy0]

Undo/Redo is also unreliable with List Block as well. I haven't fully had time to test it, but Undo will often times not be able to be Redo'd.

[aduth]

Not sure it's entirely related to what's seen, but it occurs to me that since the title field is "controlled" by editor state, it should have its default Undo/Redo behavior absorbed by the application handler.

This should already be happening, looking at the implementation:

gutenberg/packages/editor/src/components/post-title/index.js

Lines 70 to 88 in c8c1381

	/**
	* Emulates behavior of an undo or redo on its corresponding key press
	* combination. This is a workaround to React's treatment of undo in a
	* controlled textarea where characters are updated one at a time.
	* Instead, leverage the store's undo handling of title changes.
	*
	* @see https://github.com/facebook/react/issues/8514
	*
	* @param {KeyboardEvent} event Key event.
	*/
	redirectHistory( event ) {
	if ( event.shiftKey ) {
	this.props.onRedo();
	} else {
	this.props.onUndo();
	}
	event.preventDefault();
	}

Ideally there'd be some more reliable way to intercept / override the Undo & Redo, but at least for Cmd+Z (Ctrl+Z) and Cmd+Shift+Z (Ctrl+Shift+Z), the behaviors should operate on the store's history.

[aduth]

This needs specific steps to reproduce. As described in #12075 (comment) , it's expected the title edits should be reflected correctly in state for coordination by the Undo / Redo behavior, and key commands intercepted.

Edit: Sorry, I'd just seen the comment at #5685 (comment) and video from #12075 (comment) . I suppose it's specific to this case where manually adding and then removing text from the title makes those earlier additions unreachable by history? It may need more testing in how this sort of thing might behave in other native contexts, as it could be an expected behavior. The specifics of the implementation are such that consecutive edits to the same field or block attribute are grouped together into a single "undo level", so for all intents and purposes those additions are not recorded because they are later removed in the same sequence of events.

[ehti]

We tested this in core editor triage.

Able to replicate the behavior where the title doesn't get deleted when Redoing.

[ehti]

GIF credit Dan:

[paaljoachim]

Testing with WordPress 5.7 beta 3.

It seems to be working fine.
I will close. If I am mistaken, then the issue can be reopened.
Please add test instructions to that I can correctly test.
Thanks.

[paaljoachim]

I noticed that the last letter in the post title was not added back on redo.
So there is still an error here.

[Mamaduka]

I can still reproduce the issue mentioned in #12075 (comment). The post title doesn't get deleted during redo.

@paaljoachim, the post title is correctly restored for me on the redo.

Screencast

CleanShot.2022-12-13.at.14.36.57.mp4

[paaljoachim]

Great to hear George @Mamaduka !
Let's close this issue, and if for whatever reason it needs to be reopened then it can be so.

[Mamaduka]

Sorry, @paaljoachim. It looks like my issue confirmation comment was a little confusing :)