Gutenberg-mobile: No new block detected when typing fast

[mzorz]

On Android, if you tap very fast and hit ENTER and continue typing (almost all as part of the same sequence / action), the ENTER is not detected hence no new block is split, but weirdly enough the block validation error doesn't get triggered as well.

[koke]

I haven't been able to reproduce this exact thing, but I noticed that if I start typing to fast in a new paragraph, the second character is ignored.

[hypest]

What's the device and Android version you encountered this on @mzorz ?

I tried the demo app on a Pixel 2XL (Android 9) and however fast I try to type (including trying it via Vysor from the desktop) the Enter is picked up, the block is split and the rest of the characters also picked up. The only thing I noticed it that the Enter has some lag before it actually causes the split.

[mzorz]

What's the device and Android version you encountered this on @mzorz ?

I first noticed this on a Pixel 2 with Android 8.1, will now try again with latest develop to see if this is still valid and / or update the description with up-to-date behavior.

[mzorz]

Ok it felt harder to reproduce now but managed to do so on the same device (Pixel 2, Android 8.1) as can be seen in the video here
https://cloudup.com/c3ugm0Ze1a5

I _think_ I managed to do so more frequently when also tapping the formatting toolbar icons (like bold, italic, etc), but not 100% sure as I've seen it happen too while only tapping on the character keys and Enter.

[hypest]

Thanks for trying to repro again @mzorz .

FWIW, my running hypothesis for the bug's root cause is the (slow) performance of the editor. Especially when the block changes height, when focus moves and such.

[daniloercoli]

my running hypothesis for the bug's root cause is the (slow) performance of the editor.

Mine as well.

I remember I had seen this this problem weeks ago. Now it seems a little better, since cannot reproduce the problem, albeit I noticed that writing fast + tapping Enter.Key + keep writing does add the "new" characters into the original block for a little while. Then a new empty block is created, and the previous block is reset with all the content before the enter.key. In details

• Write fast in a para block
• Press Enter + keep writing
• You will notice that the new line is not inserted in the current block (which is the correct behavior) but all the other characters are inserted and visible on the screen for a short period of time
• Then then system creates the new para block
• The previous block content is reset to the content before the Enter.key

All of these problems are due to the poor performance of the editor, plus all the events that travel Native <--> JS side. Not sure how we can fix these once for all, I tried to disable input on the current TextInput field immediately after the enter.key was pressed, and re-enabled it after 250ms/500ms. But when you do this, the caret is moved to another TextInput field (the first on the list) and then moved back to the new block, making the UI/keyboard jumping around.

We should also consider that we're testing in dev mode ON, with all the RN logging turned ON. I hope better performance are seen in production. In any case i think we can lower the prio of this issue.

[mzorz]

my running hypothesis for the bug's root cause is the (slow) performance of the editor.

Agreed!

In any case i think we can lower the prio of this issue

Agreed with this as well, it doesn't seem to be a blocker at all, and only happens to appear when typing super fast randomly, which doesn't mimmick real conditions.

[hypest]

I think I'll plan to work on performance soon, during our HACK week so, I'm cool with leaving this aside for a bit.

[koke]

If I’m understanding this right, the problem is the delay between when a new paragraph is created and when it actually gets focus? (In which periods everything typed goes to the previous block)

[mchowning]

only happens to appear when typing super fast randomly, which doesn't mimmick real conditions

One somewhat realistic scenario where this can arise--I can imagine a user tapping the enter quickly a few times to create a few new paragraph blocks. In that case, this issue results in one of the middle paragraph blocks being selected (which one depends on how fast you tap the enter key) instead of the last one created (on Android at least, I can't check iOS).

Steps:

1. Edit a paragraph block
2. Quickly tap the enter key multiple times
3. Observe that the bottom paragraph block is not active.

We should also consider that we're testing in dev mode ON, with all the RN logging turned ON.

That's a really good point! I had some trouble creating a release build though, so I'm doing :point_up:

[hypest]

1. Edit a paragraph block
2. Quickly tap the enter key multiple times
3. Observe that the bottom paragraph block is not active.

Tried the steps @mchowning mentioned above, on my S7Edge with WPAndroid v12.9.rc-3 (release version of gutenberg-mobile v1.9) and couldn't see an issue. The caret correctly lands on the last of the paragraph blocks created by each successive tap on the (virtual keyboard) Enter key. Also tried quickly entering more text before hitting the Enter and continue inputting text after it and I see no problem. Maybe a slower device can exhibit the issue.

At this point, I think we need more steps to reproduce but using the release version of the app. Until then, I will close this ticket and we can reopen if/when needed.