Writing Flow: Fix all the broken flows

[aduth]

This pull request seeks to remedy a number of issues with writing flow, some of which have existed for some time, some of which have been introduced (blaming myself) in recent refactorings. This includes...

• Inserting a block should only shift focus to a text field, otherwise focusing the block's "focus stop"
  • Example: Inserting image should focus the top-level placeholder and show a black border
  • Regressed in Writing Flow: Move selected block focus to BlockListBlock #5102
• Pressing backspace or enter from the block focus stop should respectively delete or insert a subsequent paragraph block
  • Example: Pressing enter or delete on an image placeholder
  • Regressed in a combination of Writing Flow: Move selection to block's focus handler #5289 (moving tabIndex to wrapper) and Block: Avoid rerendering when the previous/next block updates #5025 (failure to update one instance of this.props.previousBlock)
• Pressing escape in a block should do nothing
  • Arguable whether this is the desired behavior, but it is consistent with native inputs. Master is in a worse state because the block becomes deselected but the text caret is not removed, causing issues because the block never again becomes selected (because isSelected is synced to its focus event, but focus has never left).
  • Regressed in Framework: Drop the focus/setFocus props from block edit functions #4872 (removal of blur)
• Pressing arrow down from a non-text-field should proceed with tab transition as expected.
  • Example: Add an image placeholder block and some text blocks following it. Arrow back to the image block. Once black border appears, press tab so focus is placed at the "Upload" button. Then press down. The text caret should be in the next text block (in master, it skips to the end of the block list).
  • This has never worked correctly.
• Multiselection at last text field in a block now accounts for non-contenteditable text fields
  • Not aware of any existing blocks which are structured this way, but there was an inconsistency between how we treated arrow tab transitions and the multi-selection shift-to-expand-only-at-last-available-field-in-block
• Better identification of text fields for writing flow transitions
  • Previously, if a block contained a checkbox, radio, or other non-text input tags, they would be erroneously included in the writing flow sequence.
  • This has never worked correctly.

Implementation notes:

I'm hopeful the changes here provide more stability by consolidating like behaviors and isolating typing behavior outside the block itself.

Managing isTyping was moved to a separate component, largely because there was conflicts with IgnoreNestedEvents when both the block's inner and outer wrappers listen on the same block. I had started to explore providing a label to identify block handled events per block UID, but instead decided to refactor the typing logic altogether. The intention here is that isTyping is a global behavior, not specific to individual blocks (especially as we'd previously had handling re-setting isTyping after a separate block becomes selected after merge/split, and had separately handled logic of "is typing within block").

Because I'm guilty of causing much of these regressions in refactoring, I am committing myself to writing end-to-end tests for these behaviors.

Testing instructions:

Verify that all the writing flows work correctly. Notably all the examples above plus:

• Inserting paragraph block (quote, etc; those with text fields) via autocomplete moves focus to cursor
• Inserting image block (or others without text fields) via autocomplete causes focus to stay at block wrapper with black border
• Shift-arrow from an text field incurs multiselection, but not if there are other text fields in the intended direction in the same block
  • Shift-up from quote's text causes multi-selection upward
  • Shift-down from quote's text causes caret to move into citation
  • Shift-down from quote's citation causes multi-selection downward
• Block splitting and merging moves caret to correct position, and causes isTyping flag to be set if not arleady
• Block controls disappear when typing (either input, arrow keys, enter/backspace/delete)
  • Block controls reappear when mouse moved or shift-selection (uncollapsed selection)

[jasmussen]

Thank you so much for working on this. This is a 🔥PR and a masterclass in code. 👏

Inserting a block should only shift focus to a text field, otherwise focusing the block's "focus stop"
Example: Inserting image should focus the top-level placeholder and show a black border

Works really well 🌟

Pressing backspace or from the block focus stop should respectively delete or insert a subsequent paragraph block
Example: Pressing enter or delete on an image placeholder

🌟

Pressing escape in a block should do nothing
Arguable whether this is the desired behavior, but it is consistent with native inputs. Master is in a worse state because the block becomes deselected but the text caret is not removed, causing issues because the block never again becomes selected (because isSelected is synced to its focus event, but focus has never left).

🌟

Agree that it's unclear what is the ideal behavior here. It sort of conflicts with #4382 (comment), but there isn't wide consensus on the approach outlined there, so we can always revisit if and when that becomes necessary.

Pressing arrow down from a non-text-field should proceed with tab transition as expected.
Example: Add an image placeholder block and some text blocks following it. Arrow back to the image block. Once black border appears, press tab so focus is placed at the "Upload" button. Then press down. The text caret should be in the next text block (in master, it skips to the end of the block list).

🌟

Multiselection at last text field in a block now accounts for non-contenteditable text fields
Not aware of any existing blocks which are structured this way, but there was an inconsistency between how we treated arrow tab transitions and the multi-selection shift-to-expand-only-at-last-available-field-in-block

🌟

Better identification of text fields for writing flow transitions
Previously, if a block contained a checkbox, radio, or other non-text input tags, they would be erroneously included in the writing flow sequence.

🌟 🔥

Inserting paragraph block (quote, etc; those with text fields) via autocomplete moves focus to cursor

🌟

Inserting image block (or others without text fields) via autocomplete causes focus to stay at block wrapper with black border

🌟

Shift-arrow from an text field incurs multiselection, but not if there are other text fields in the intended direction in the same block

🌟 CC: @iseulde

I think this is desired behavior, it feels right, but I feel like Ella and I discussed in the past what happened if you were in a multi input block, held shift, and arrowed. Can't recall the full details.

Shift-up from quote's text causes multi-selection upward
Shift-down from quote's text causes caret to move into citation
Shift-down from quote's citation causes multi-selection downward

🌟🌟🌟

Block splitting and merging moves caret to correct position, and causes isTyping flag to be set if not arleady

🌟🔥🚒

Block controls disappear when typing (either input, arrow keys, enter/backspace/delete)
Block controls reappear when mouse moved or shift-selection (uncollapsed selection)

🌟

Amazing work! This is suuuch a vast improvement to the writing flow. Really really dig this. 👍 👍

[aduth]

Thanks for the glowing review @jasmussen ! And for running through all the steps.

It's a risky move forward with the code changes, but I want this one to have some time to sit in master to let any issues surface before the pending release, so I'm going to go ahead and merge.

[ellatrix]

I think this is desired behavior, it feels right, but I feel like Ella and I discussed in the past what happened if you were in a multi input block, held shift, and arrowed. Can't recall the full details.

Yes, this is still a to-do. See #3232.

---

Thanks for all the work on this @aduth. I've been testing shift-arrow-multi-selection a bit, and it seems broken if you go in one direction for a while, and then the other. Not sure if this ever worked as expected but I think it did. I'm expecting shift+arrow in the opposite direction to deselect the blocks again one at the time. I'll see if I can fix this.

[aduth]

I've been testing shift-arrow-multi-selection a bit, and it seems broken if you go in one direction for a while, and then the other.

Yes, this was identified as a "Known bug" of the nesting implementation (#3745 (comment), #3745 (comment)), but good to have an explicit issue for it (#5548). Thanks!

[mcsf]

This is awesome.

[aduth]

I'm trying to recall if there was a specific reason to make this bound to the document, vs. just an onSelectionChange event on the div wrapper. It was inherited from how this was applied previously, originally from #4872, where the selection handling moved from RichText to BlockListBlock.

The document-based mousemove event makes sense because we want to unset typing even when the mouse is moved outside the descendents of this component. But selectionchange? I'm not sure. That seems inconsistent with the rest of the key handling that happens here.

[aduth]

Ah, this would probably explain why:

facebook/react#5785