Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search inserter - Issue when searching a block while the title is focused #30562

Closed
geriux opened this issue Apr 7, 2021 · 6 comments · Fixed by #53217
Closed

Search inserter - Issue when searching a block while the title is focused #30562

geriux opened this issue Apr 7, 2021 · 6 comments · Fixed by #53217
Assignees
Labels
Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Priority] High Used to indicate top priority items that need quick attention

Comments

@geriux
Copy link
Member

geriux commented Apr 7, 2021

Description

While testing something on develop, I found an issue with the Search inserter, since it's still under DEV is not a blocker or anything but definitely something to be fixed before releasing this feature.

If you have the Title component focused and then try to add a block by using the Search inserter, something weird happens with the focus, looks like it gets into a loop.

Note: This doesn't happen if a Paragraph block is focused instead of the title. This does happen if a Paragraph block is focused instead of a title – as long as that block has text (i.e. is not empty) – see video below in #30562 (comment).

Step-by-step reproduction instructions

If using demo app:

  • Open the demo app
  • Focus on the Title section

If using the WordPress app:

  • Open the app with metro running
  • Start a post and expect to see the editor and the title component focused.

Next steps:

  • Tap on + to open the Inserter.
  • Within the search box, type Buttons.
  • Tap on the Buttons block to add it.

Expected behaviour

  • The Buttons block should be focused after adding it without any focus issues.

Actual behaviour

  • The title remains focused.
  • When trying to tap on the Buttons block you can't, seems like it gets into a focus loop.

Screenshots or screen recording (optional)

SearchInserter.mov

Device information

  • Device: iPhone 12 Pro simulator
  • Operating system: iOS 14.4
@geriux geriux added the Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) label Apr 7, 2021
@geriux
Copy link
Member Author

geriux commented Apr 7, 2021

Hey @jhnstn 👋 have you encountered this issue before?

@jhnstn
Copy link
Contributor

jhnstn commented Apr 7, 2021

@geriux I have not run into this issue. Thanks for catching it!
I'll get it fixed before we release.

@jhnstn jhnstn self-assigned this Apr 7, 2021
@mchowning mchowning added the [Priority] High Used to indicate top priority items that need quick attention label Apr 8, 2021
@AmandaRiu
Copy link
Contributor

AmandaRiu commented Apr 19, 2021

Just a note that I was not able to reproduce this issue, but @dcalhoun was with his iOS device. When I tested it I did it with an emulator and simulator. I'll test again using physical devices today and see if I can reproduce the issue that way and report back.

@AmandaRiu
Copy link
Contributor

@jhnstn I wasn't able to replicate this issue on any of my Android devices, but was able to do it with my physical iPhone 11 (iOS v. 14.4.2):

screencapture-1618854323923.mp4

@guarani
Copy link
Contributor

guarani commented Jun 22, 2021

I spent some time investigating this and although I didn't manage to solve the issue, here's what I found:

Focus loop affects all blocks

First of all, in my testing, this issue (the focus loop) is not specific to the post title. It also happens when any block (e.g. a Paragraph block) has an input which has keyboard focus AND has some text in it AND then a block is inserted via the block inserter search.

RN 0.64 upgrade did not fix focus loop

I found this issue to still be present on trunk after we upgraded to React Native 0.64.

Focus loop is not specific to the Block Inserter Search

In my testing, any input field (e.g. a raw TextInput) that is added to the block inserter bottom sheet exhibits the focus loop. Take this example:

  1. Add a TextInput to the Block Inserter bottom sheet's code
  2. Add a Paragraph block to the editor and type some text into it
  3. Ensure the Paragraph block still has keyboard focus
  4. Open the block inserter and tap the TextInput to give it keyboard focus
  5. Tap any block in the inserter to add it to the editor (e.g. a Heading block)
  6. Notice the focus loop

Next steps

I don't think this issue is related to the block inserter search itself (as noted above). One area of interest in this investigation was the code that enables the editor to return keyboard focus back to the input that had keyboard focus prior to the bottom sheet being opened. It's conceivable that this code could be key to understanding the cause of this focus bug.
I wasn't able to locate this code myself, but @enejb pointed me to https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/block-list/block.native.js#L113. I haven't yet followed up on this because my attention was diverted to other issues.

@guarani
Copy link
Contributor

guarani commented Jun 22, 2021

Note: This doesn't happen if a Paragraph block is focused instead of the title.

I'm updating this sentence of the original issue to indicate that the bug is present on other blocks – as long as that block has text (i.e. is not empty) – see video below. Worth noting that I'm testing using RN 0.64 and iOS 14.5.

plain-paragraph.mov

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Priority] High Used to indicate top priority items that need quick attention
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants