Writing Flow: Avoid auto-focus on nested blocks

[aduth]

Related: #4872 (comment)

This pull request seeks to resolve an issue where it is difficult to use the ellipsis More Options menu for the Column block due to focus transitioning into the block. The changes here revise the logic for focusing the newly-selected block to ensure that the selected block is not within a nested block, since if it is, the selected block will change and the menu will become dismissed.

Testing instructions:

Verify that you can open the More Options ellipsis menu, both for the Columns block and a non-nesting block. In the latter case, ensure that focus is still transitioned within the block.

Verify there are no regressions in the behavior where this auto-focus behavior is necessary:

• Block splitting
• Block merging
• Block replacement (paste)

[youknowriad]

This breaks some behaviors:

• splitting inside container blocks like "columns".
• selecting an image and hitting Enter inside container blocks

[aduth]

Hmm, I can confirm this, though I wouldn't have expected it, since these behaviors should be finding inputs within the selected block, at which point it should be finding the selected nested's inputs correctly. Will investigate...

[aduth]

There's a few related issues which contribute to the breakage in nested writing flow:

• A block's selection occurs in mousedown, whereas DefaultBlockAppender responds to click, meaning when clicking the default block appender in a columns block, the "Columns" block will become selected before the insertion, and per the logic introduced here, avoid focusing anything since at that point, the default block appender (read only) is still present in the DOM
  • Fix may be to either change DefaultBlockAppender to append onMouseDown, or change BlockListBlock's to select onClick
• When splitting blocks in a nested paragraph, the WritingFlow logic for finding the selected block produces a null value. Presumably the newly split block is not yet in the DOM. This doesn't occur at the top-level (correctly finds the newly split block), and I'm not yet sure why there's a distinction.

[aduth]

Or we could add a setTimeout to the WritingFlow's block selection focusing 😬

[aduth]

A block's selection occurs in mousedown, whereas DefaultBlockAppender responds to click, meaning when clicking the default block appender in a columns block, the "Columns" block will become selected before the insertion, and per the logic introduced here, avoid focusing anything since at that point, the default block appender (read only) is still present in the DOM

On second thought, even though this is true, the later insertion of the default block should change the selection and trigger another WritingFlow component update...

[aduth]

In fact, I think these are the same issue: That the second component updates, but the new default block isn't yet present in the DOM, same as noted for splitting.

[youknowriad]

@aduth This might have an impact here #5100 It could fix some of the undesired focus calls.

[aduth]

Closed in favor of #5102