Wp-calypso: Gutenberg Editor: Classic Block removes content that cannot be "redo[ne]" when using keyboard shortcuts [Ctrl/Cmd + Z]

[TeniCola]

I wanted to bring attention to a strange quirk, that feels like a potential bug, in the Classic block and how it responds to keyboard shortcuts for "Undo". In brief, if you type this keyboard shortcut while working in the Classic block, it will remove all content and/or changes at once, and that content cannot be "Redo[ne]" back.

Steps to reproduce

1. Starting at URL: Any post or page in the WordPress.com editor, any publish status.
2. Create a classic block, and start typing content, maybe a few sentences or paragraphs. Keep typing, take pauses, adjust formatting, do whatever feels like a normal pace for writing.
3. On your keyboard, press [Control + Z] on Windows, or [Command + Z] on Mac, to use the "Undo" function. You should see most if not all of your content removed; in my case, the entire block goes away.
4. Try to "Redo" what you just removed using any available methods -- Keyboard shortcuts, or any of the visual buttons on the editor or Classic block.

What I expected

For the block to bring back all the content I just typed and formatted -- no matter how much it removed when I clicked "Undo" -- based on how these two shortcuts normally behave.

What happened instead

The classic block may return, but otherwise _nothing_ -- the content is gone, and no amount of "Redo" brings it back into the Classic block. If it wasn't saved before, it's not going to be found in Revision History, either.

Screenshot / Video

See the following 2-minute video to view how I replicate this behavior on my Macbook (Chrome), twice: https://d.pr/v/rOJy9U

I did use lorem ipsum snippets for some of the text for the sake of the video, but it replicates the same way if you type everything manually. Worth noting, this behavior is very distinct from the way that the Undo shortcut works if you type in different paragraph blocks, or if you use the Classic Editor.

Other observations are the following that I captured in screenshots:

(1) The quirk from the keyboard shortcut is different from the on-screen buttons on the editor and in the Classic block; those work as expected when you click them, as follows: https://d.pr/i/JYB8BO

(2) The Classic block indicates that the keyboard shortcut is _meant_ to work the same way as the on-screen buttons. When you hover over the icons, they display the same shortcut suggestion based on your device -- so anyone who sees it will expect the same behavior, and not what currently happens: https://d.pr/i/VLASKJ

Browser / OS version

So far I have tested and replicated this behavior on my MacBook and my PC (Lenovo), using Chrome Version 83.0.4103.61 (Official Build) (64-bit). So it replicates on different OS's, but I have yet to test this in other browsers.

Context / Source

I discovered this quirk by chance because I use the keyboard shortcut habitually across different programs. The Undo shortcut is universal in many programs, so I expected it to behave the same way the Classic Editor -- not expecting that content would be lost and non-recoverable. The few times it got me was with working on P2 updates and losing all my formatting and links.

I think this behavior may be worth looking into, or at least monitoring, in case this happens for other users who rely on the Classic block -- in particular, for users transitioning to the Block editor who may want to use the Classic block exclusively. This bug has the potential to remove a lot of content that can't be recovered.

Ideally, it might make sense to have the keyboard shortcuts for Undo and Redo work just as reliably as the on-screen buttons -- probably like the icons for the Classic block, a bit at a time.

NOTE: There is a current issue in the Gutenburg repo that suggested removing the undo buttons in the Classic block, but since it works differently from the Editor's buttons, it may be worth rethinking if removing the buttons is the solution; the fine-tuned undo/redo function may be something users will want to keep.

dogfooding, #manual-testing

[pento]

Thank you for the comprehensive bug report, @TeniCola!

I'm able to reproduce this issue in a local install of WordPress/Gutenberg, which means the bug affects all Gutenberg installs, rather than just the WordPress.com copy of Gutenberg.

If you have a moment, are you able to repost this issue on the Gutenberg repository, so it can be fixed in the right place?

[TeniCola]

Thank you for the comprehensive bug report, @TeniCola!

I'm able to reproduce this issue in a local install of WordPress/Gutenberg, which means the bug affects all Gutenberg installs, rather than just the WordPress.com copy of Gutenberg.

If you have a moment, are you able to repost this issue on the Gutenberg repository, so it can be fixed in the right place?

Happy to help @pento, and thanks for checking on the local WordPress install as well!

And will do, I'll copy this issue to the WordPress repo and reference this version in a few moments. Afterwards we can consider closing this one, or locking the conversation (whichever seems best 👍 )

[pento]

Thank you for doing that, @TeniCola! I'll close this issue, we can reference it if our customers run into this problem, rather than putting internal ticket/chat references on the Gutenberg issue. Engineering work can happen over on the Gutenberg issue. 🙂