Undo: merely putting the caret in a new post creates an undo level

[ellatrix]

Describe the bug

To reproduce

1. Create a new post.
2. Place the caret in the empty post.
3. Notice that an undo level is created (undo button lights up). Also notice that the post cannot be saved, indicating that nothing changed.

Expected behavior

The content should not have changed and there should be no undo levels.

[aduth]

I don't know that this is strictly wrong in that the history reflects the creation of a block. The fact that the post can't be saved is more a consequence of the special handling of a post which contains only a single empty default block (#9808).

[ellatrix]

I understand what happens technically behind the scenes, but from a user's perspective, this feels buggy. The user didn't really create any content yet. I don't think any other editor out there would do this.

[aduth]

The user didn't really create any content yet.

I guess this depends whether the user considers the act of placing the caret as equivalent to adding a new paragraph block (which it is).

In all, I'd probably tend to agree with you that as much as we can consider the simple act of placing a caret as more akin to placing a caret into any other word processor (as a "noop"), the better (including change detection, I think).

[swissspidy]

Issues like this one, but also #12273, #12272, or for example #12271 show that unnecessary undo levels are created for non-user-driven actions. In all of these scenarios I (as a user) would expect to undo only the actions I took.

So if the history stack looks like this:

1. User action B
2. Programmatic action done by the editor C
3. Programmatic action done by the editor B
4. Programmatic action done by the editor A
5. User action A

And if I click undo, I would expect my user action B to be undone. But the editor behind the scenes would undo all the programmatic actions as well. So behind the scenes the stack would look like this in the end:

1. User action A

[aduth]

Related (some redundancy): #8119