Gutenberg-mobile: "Add new block" fails after first use

[mkevins]

The + button to add new block works once, but does not work on subsequent button presses. This issue was discovered on the Android Emulator, and has not been reproduced on a real device (attempts were made, but the issue was not encountered).

Steps to reproduce:

• Press the + button and choose new paragraph block
• Write some text
• Press the + button again and choose a new paragraph block

Result:
A new paragraph block is not created. The focus changes to an already existing block.

Screenshot:

[mkevins]

After testing this issue further, I have discovered that the + button to create a new paragraph block fails when a Heading or Paragraph block is focused, but succeeds when a Page Break block or Code block is focused.

Also, it seems that using + to add either a Page Break block, or a Code block, succeeds, regardless of which block type had focus when tapping +.

Some other discoveries:

• If a heading block is created, with no text, and focus is changed to another block, the heading block remains. I'm not certain this is the desired behavior.
• When a Page Break block is created while a textual (Heading, Paragraph, or Code) block has focus, the Page Break block becomes the active block, but a (blinking) caret remains in the previously focused textual block, but the keyboard becomes hidden. I'm not certain this is the desired behavior, but if so, I think the keyboard should remain visible. Presently, it appears as though both blocks have focus simultaneously.

Some of these issues could be same / related to #196 or #311.

[mkevins]

The recent upgrade (React Native to 0.59, React to 16.8.3) seems to have a source map issue, which has made it difficult to use the JS remote debugger. I am temporarily resorting to a bisection method to try to isolate the changeset that may have introduced this issue. I will test this issue manually using the following steps:

1. Place the cursor at the end of the "Hello World!" block
2. Press the + button and add a new Paragraph block
3. Observe success or failure
4. Mark hashes / tags below with a [*] for success, and [ ] for failure

Progress:

• [ ] 2f145b - 2019-04-02 15:16 - HEAD
• [ ] acd685 - 2019-03-28 11:32 -
• [ ] 0b22a1 - 2019-03-22 17:31 -
• [ ] 9a72ec - 2019-03-19 15:55 - Merge remote-tracking branch 'origin/develop' into update/gutenberg-re
• [ ] 843113 - 2019-03-19 12:52 Merge pull request #736 from wordpress-mobile/issue/715-request-canc
• [ ] 08a096 - 2019-03-15 16:47 Merge pull request #741 from wordpress-mobile/upgrade-to-rn-059
• [ ] 11220f - 2019-03-15 12:43 Merge branch 'develop' into upgrade-to-rn-059
• [x] b24c95 - 2019-03-15 08:48 Fix merge conflicts
• [x] 4ab812 - 2019-03-15 08:34 Merge branch 'develop' of https://github.com/wordpress-mobile/gutenber
• [x] 5ce3e1 - 2019-03-14 16:52 Update gb hash after merging the companion PR
• [x] d57b37 - 2019-03-14 10:00 - Tests: Add mock for the newly added CSS class
• [x] b5860f - 2019-03-08 21:10 -
• [x] 78c8cf - 2019-02-22 19:16 -

I began this bisection manually, explicitly selecting release tags / versions to narrow the scope at that level of granularity. The results so far indicate that the regression was introduced somewhere between v1.1.0 and v1.1.1. I then proceeded manually, increasing the granularity to mostly PR merges, at first in timestamp order, then by transitioning to topological ordering.

I encountered a few commits (as expected) that either did not build, or began with a red screen at startup, because the process is agnostic to whether or not a commit represents work in an "unfinished" state.

I went a little bit further with git bisect. Several commits near the condition boundary result in a failed build, so progress has slowed. Attached below is the log from git bisect.

bisection-log-783.txt

From a coarse view, this issue appears to have been introduced during the upgrade to RN 0.59, but I have not pinpointed the exact commit.

[daniloercoli]

Fixed in https://github.com/wordpress-mobile/gutenberg-mobile/pull/857