After two blocks are merged, show cursor on the end of the text field

[marecar3]

Based on issue: #699

Corresponding gutenberg PR : WordPress/gutenberg#14820

There are two issues :

Issue A: After two blocks are merged, a cursor will be placed on the last remembered position in the block. (Affected both iOS and Android platform)

Steps to reproduce:

1. Create a new Gutenberg post with 2 simple paragraph blocks
2. Put the cursor somewhere in the first block except its end
3. Go to the end of the second block and start backspacing to delete characters. Delete up until the very first character of the second block
4. Notice that the "Start writing" placeholder text appears
5. Notice the caret is placed at the position set in step 2

Issue B: When the user clears the text in the e.g. Paragraph/Heading block, a block will be merged right after the last letter is deleted. (Affects only Android platform) - Which should be a case, as on iOS block will be merged after one extra backspace.

Steps to reproduce:

1. Create a new Gutenberg post with 2 simple paragraph blocks
2. Go to the end of the second block and start backspacing to delete characters. Delete up until the very first character of the second block
3. Notice that the "Start writing" placeholder text appears
4. After a small delay the focus moves to the first block. Sometimes the whole second block gets removed, some time is stays there. This step only happens on Android. On iOS, you need to backspace once more to cause the block merge.

Hey @daniloercoli , @mzorz at this point I invested some extra time and I couldn't find a better solution so I am very open to hearing your suggestions if you have something on your mind. I tried to find some common solution which would be placed in JS code, but it seems that it couldn't be doable from JS side. I will mark this one as ready for review very soon so that you can start reviewing it.

[daniloercoli]

For the Issue A wondering if we can expand the code added here https://github.com/wordpress-mobile/gutenberg-mobile/pull/629/files#diff-5693404c4c8f8d757cd298cc5aabc561R117 introduced to set the caret at the end of text when getting the focus.

[marecar3]

Hey @daniloercoli , thanks for the good point. Please take a look at new iteration :)

[mzorz]

Hi! I've been looking into this for a while, results of my tests here:

ISSUE B:

1. start a draft, place 2 paragraph blocks with some text
2. place cursor at first block
3. place cursor at end of second block
4. press and hold BACKSPACE, it will repeat backspace and delete each character rapidly
5. observe it stops when there's nothing else to delete so, issue described in Deleting all contents of block moves cursor to last location in previous block #699 is ok with this new PR 👍

ISSUE A

This one is still happening for me.
I started debugging the onTakeFocus() method in ReactAztecArrowKeyMovementMethod class, and I realize that when you press backspace for the second time, if (view.getLayout() == null) returns true, so it gets into that code path. Even so though, that code path tells the EditText to place the cursor at the beginning, but it doesn't work (or it does and then somehow we're placing the cursor back again where it originally was? IDK).
So 2 issues here, one is the layout being null (1), the other one about the selection not catching up correctly (2).

• Re: (1): back to the Android docs, the docs say this https://developer.android.com/reference/android/widget/TextView.html#getLayout()
  Furthermore, checked where the original code was introduced, it's this commit here 538fb9c#diff-5693404c4c8f8d757cd298cc5aabc561
  and the code is taken from the original Android source code, except that it doesn't tell the TextView to place the selection at the beginning but rather at the end of text. IDK if getting a null here is in fact an issue itself but, wondering about the comment in the original source code where it states that it shouldn't be null. I think this one can probably be left as is as there doesn't seem to have visible harm, but stating it here in case there's some relationship to other things going on at the same time.

• Re: (2) I'm investigating this now, and it seems that setSelection() when the focus changes gets called for the "last" position of the focus and even the last time it gets called is the one in ReactAztecArrowKeyMovementMethod as expected, but still the EditText shows otherwise. That was my first attempt as I thought maybe we're re-setting it from the outside, but doesn't seem to be the case. I'll try now seeing if we need to refresh the view somehow. Just wanted to give the heads up I'm trying to look further and make sense.

Question, does this (2) happen for you @marecar3 ? I'm using a Pixel 2 with Android 8.1 to test.

[mzorz]

Added PR (comparing branch against this one) to try and fix (2) above here #765

[marecar3]

Hey @mzorz, I have noticed that we introduced some regression, this is the scenario :

1. Create some paragraph with text
2. Put the cursor in the middle of the text
3. Press enter to break the text
4. The new block is created

Result -> On the newly created block cursor is at the end of the text
Expected -> Cursor should be at the beginning of the text

[mzorz]

Result -> On the newly created block cursor is at the end of the text
Expected -> Cursor should be at the beginning of the text

🤔 maybe is it due to this change here? https://github.com/wordpress-mobile/gutenberg-mobile/pull/765/files#diff-6d32b8ead802ea7e00caa5563c2239c3L33

[mzorz]

Just a FYI I was trying something here #773, still need to work more on it but open to any suggestions

[marecar3]

Hey @mzorz, thanks for heads up. Will look at it and I am also trying some ideas.

[marecar3]

Hey Hey @etoledom @mzorz @daniloercoli @pinarol, I have moved the logic to the JS side so if you have time please take a look at this PR and corresponding gutenberg PR : WordPress/gutenberg#14820

[mzorz]

Tested, code LGTM! Thanks for this @marecar3
Feel free to merge after resolving conflicts

[marecar3]

Will merge this one as it seems that the same tests are also failing on the develop branch.
cc : @JavonDavis @hypest