Tapping on a Page Break block does make the block-holder selected but keep the keyboard up, and the caret to the Para block

[daniloercoli]

This is related to #306 - This time the selection of Page Break block happens by the "user" with the cursor/tapping, instead of programatically like in #306, but the end result is the same.

Steps to repro:

• Tap on a para block
• Tap on the page break block
• The block holder is selected, but the soft keyboard is still up, and the caret blinking in the previous para block
• If you tap on the keyboard characters are inserted in the para block

[hypest]

Added this to the Alpha milestone but it's not a blocker for the Alpha.

[koke]

I think this is a duplicate of #197?

When a non textual block (e.g. image, more) is selected, hide the keyboard.

I think we want this for the alpha, focus should follow the selected block, it's really confusing when it doesn't

[daniloercoli]

Re-opened this since the fix introduced a problem with the keyboard. (#383)

[daniloercoli]

The tentative fix for this issue is available here: WordPress/gutenberg#12765
but then reverted since introduced a problem with the Keyboard dismissed when tapping Enter. Details: #381 (comment)

[daniloercoli]

As per chat convo, this here https://github.com/facebook/react-native/blob/1151c096dab17e5d9a6ac05b61aacecd4305f3db/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java#L46 should be the right direct to go (removes the nasty side effect that EditTexts have, which is that focus is always maintained on one of the EditTexts).

[koke]

removes the nasty side effect that EditTexts have, which is that focus is always maintained on one of the EditTexts

For reference, I think I managed to work around that by adding this in the app:
https://gist.github.com/koke/b572a7c4e203bf92c50d7c57b614e82c

However that didn't solve the keyboard being dismissed. I think the logic was right to dismiss the keyboard from RichText on split, but then the new block wasn't regaining focus. My hypothesis is that we handle the focus on componentDidUpdate, which won't get called since it's a newly created component, not an update to an existing one. We might have to replicate some of it on componentDidMount, but I haven't tested any of that.