Undo/redo: cursor positioning on Rich Text-based blocks after undoing is pos+1

[mzorz]

1. insert a character in the middle of a word, for example place the cursor after "Wel" in "Wel|come to Gutenberg" and tap space
2. tap undo
3. observe the action is undone, but the cursor appears one character more to the right than initially, that is in "Welc|ome to Gutenberg"

[koke]

OK, this got worse. Instead of the cursor moving, the whole text disappears

[koke]

[koke]

Confirmed as well on iOS. The text isn't deleted every time, sometimes I see the cursor thing only

[daniloercoli]

While investigating this problem found out that we're only storing the content of the block in history, then when the user taps on the undo/redo buttons the content of the block is changed but the caret position is not updated.
The web side is working on adding this info in history, so let's wait until the GB side PRs are merged and ready, since there are many problems to tackle about the caret position and restoring it.
Ref: #884 (comment)

[SergioEstevao]

I just tested this again on iOS, and it looks there are sync issues between the selection/move of the cursor and the writing of the text.
Sometimes when pressing undo the character inserted is undo and then selection/move other times is the other way around.

[mchowning]

This may not be directly related since I'm only seeing this on Android, but I see that an extra undo point to move the cursor is getting created on Android when adding words to a paragraph block.

Steps to Reproduce

1. Open a new post
2. Add two words to the post by swiping
3. Tap undo and observe the second word only is removed (the first word remains)
4. Tap undo a second time and observe the cursor is moved to the beginning of the paragraph block, but the word is not removed.
5. Tap undo a third time and observe the remaining word is removed.

[maxme]

cursor positioning on Rich Text-based blocks after undoing is pos+1

I was able to reproduce this one on a recent version (alpha-233). Cursor moves "randomly" after the undo (sometimes one more character to the right).

[maxme]

Moved from High prio to Medium, I wasn't able to reproduce the content loss (like in #303 (comment))

[designsimply]

Some improvements were made to undo/redo in 15.6. See WordPress/gutenberg#24116. Props @dratwas. 🎉

During beta testing for 15.6, I found that the cursor still moves around unexpectedly as described in this issue. I also didn't experience any content loss as maxme also mentioned above. 👍

In my case, when adding a few sentences to the beginning of a paragraph block then removing them with undo, the cursor always seemed to land one character short of where I think it should be landing (pos-1 instead of pos+1).

^{Tested with WPiOS 15.6.0.1 TestFlight beta on iPhone 11 iOS 13.6.1.}

When I tried the original steps for this issue, I found that the cursor landed at the end of the most recently added text when I added a space to the middle of a word then tapped undo.

^{Tested with WPiOS 15.6.0.1 TestFlight beta on iPhone 11 iOS 13.6.1.}

When I tried the steps from mchowning's comment, I found that it only took two undos to remove the two words added but the cursor jumps to the beginning of the text after the first undo which is unexpected.

^{Tested with WPiOS 15.6.0.1 TestFlight beta on iPhone 11 iOS 13.6.1.}

[hypest]

This ticket is not worked on at the moment so, I'll clear the assignee field to denote so.

[ceyhun]

This is still reproducible but there's a debounce of 1 second. The steps are:

1. Type letter "A"
2. Wait 1 second
3. Type letter "b"
4. Wait 1 second
5. Press undo
6. The cursor goes to the position before the letter "A" but it should be after it.

Result

^{Tested with GutenbergDemo app 1.40.0 iPhone 11 simulator on iOS 14}

Action

State Diff

The RESET_SELECTION action seemed to be getting called with wrong offset value, but didn't have enough time to trace the root cause.

[AmandaRiu]

FYI: Still an issue as of 1.57.0. Tested on a physical Pixel 4 running Android 11 w/ Gboard:

screencapture-1626125491626.mp4

[SiobhyB]

Noting that this can still be replicated, most recently tested on an iPhone XR with the pr18445-7dc96cb build.