Keyboard navigation when inserting a block has unexpected behaviour

[moorscode]

Describe the bug
Keyboard navigation when inserting a block, underneath the lowest block, has unexpected behaviour.

To Reproduce
Steps to reproduce the behavior:

1. Go to a page
2. Click on adding a new block
3. Type to search in the blocks, e.g. "image"
4. Try to use the keyboard navigation to select the block you want to insert
5. See the navigation of the blocks being affected, instead of selecting the blocks that resulted in the search
6. As this removes the focus from the "Add block" modal, it will disappear

Expected behavior
I expect to be able to select a block to insert, using the keyboard only

Additional context
Gutenberg 3.6.x & 3.7.0

[afercia]

I can reproduce this in the side inserter. The main inserter in the top bar seems not affected.

When the caret is in the search field, users could try using the arrow keys. Both left / right and up / down arrows trigger the writing flow, and focus goes to the blocks list.

This is not the expected behavior: when the caret is within a standard input field, for no reason, ever, arrows should move focus away. The native behavior should be preserved.

Wild guess: some event that needs to stop propagation (as noted in other issues, this should be the default in most of the cases in Gutenberg).

[afercia]

I can confirm stopping propagation of the keydown event on the search field fixes it. However, this happens everywhere in the inserter, for every focusable elements: expandable panels, block type buttons:

using the arrow keys when these elements are focused, triggers the writing flow.

[afercia]

Adding the regression label as this didn't happen on 2.9 and was introduced in 3.0.

[afercia]

I'd suggest to consider this issue together with #6468

Basically, this requires to make a decision about where Writing Flow should work. Currently, it works on any focusable element in the post content (post title + blocks list). However, there are native input fields, buttons, and other focusable elements rendered within the blocks list where Writing Flow should not conflict with native behavior of the arrow keys. The native interaction with native input fields should always be preserved, as that's the expected interaction in terms of both usability and accessibility.

I'd strongly recommend to make Writing Flow work only through textual content. After all, that's what it was designed for initially: to make the writing experience similar to the one users have in word editors. This shouldn't include native UI controls or other focusable elements that are not text.

[gziolo]

I don't see any corresponding PRs linked, moving it to 4.2 milestone.

[talldan]

I've put a PR in to fix - would be great to get some testing on it 👉 #11088