Writing Flow: Repeated multi-selection in consecutive blocks of same type limited to two blocks

[aduth]

Describe the bug

When using Shift+ArrowDown to create a multi-selection, it is not possible to select more than two blocks of the same type†.

† "Of the same type" is important to note because the block transform toolbar option only appears when the multi-selection consists of blocks of the same type. I suppose it should also be noted that it might only be an issue for blocks of the same type which have transform options.

To Reproduce

Steps to reproduce the behavior:

1. Navigate to Posts > Add New
2. Add three paragraphs
3. Select the first paragraph block
4. Shift+ArrowDown to select all three blocks
5. Observe that after the second block becomes selected, the next Shift+ArrowDown causes focus to be moved into the transform modal, rather than continuing the multi-selection.

Expected behavior

I should be able to multi-select as many blocks as I continue to Shift+ArrowDown.

[aduth]

In fixing this, we should add an end-to-end test case to protect against future regressions.

https://github.com/WordPress/gutenberg/blob/master/test/e2e/specs/multi-block-selection.test.js

[youknowriad]

So I tried looking at this and it's not an easy fix: The issue is where should we put the focus when we're on multi-selection and when.

For example, when you shift+arrow to select two blocks, do you leave the cursor in the first block's RichText or do you move elsewhere while you're still selecting (shift is still pressed)?

Right now the behavior is: we put the cursor in the block toolbar as soon as we select more than one block even if we didn't finish the multi-selection. This creates a bug when multiselecting with the keyboard because sometimes the toolbar is not displayed inside the "WritingFlow" making it impossible to continue the multiselection. And even if we showed the toolbar inside WritingFlow, it's not working great because it conflicts with the toolbar's navigation.

Should we move the focus to the container of the first block instead, I feel like this would solve all issues?

[youknowriad]

cc @jasmussen

[jasmussen]

GIF:

So as far as solutions go, can we do the following?

• When you're in a a single text block, shift tab enters the toolbar.
• When you've selected multiple text blocks, you still have to press shift tab to enter the multi toolbar.

[youknowriad]

The issue is not about entering the toolbar but about where to put the focus when multi-selecting and still allowing to continue the selection.

[jasmussen]

Gotcha, CC: @iseulde in case she has input as well.

When I click a text block and set focus on it, focus according to my bookmarklet is on:

When I press "shift tab" that puts me into the block toolbar.

Is there an equivalent in multi selections we can set focus on, where shift tab would set focus in the block toolbar? My point is that multi selection across more than two blocks still works, the problem here is that the dropdown menu opens, which means if the dropdown menu doesn't have focus, that should solve it. All we need to ensure is that the block toolbar is still tabbable.

Where is focus set when you tab to a new block? Possibly tangentially related: #9858.

[youknowriad]

The multiselection doesn't work if you're in Unified toolbar mode and I believe alt + f10 is the keyboard shortcut to navigate to the toolbar right?

[mcsf]

Possibly related: when multi-selecting with the cursor, the caret unexpectedly appearing:

(in the GIF above, it only happened the second time, likely due to Licecap interaction)

[mcsf]

Possibly related: when multi-selecting with the cursor, the caret unexpectedly appearing:

Tracked in #10617.

[youknowriad]

We're a bit short in time, if we want this in in 4.2 we should work on a PR quickly or defer to the 5.0 milestone.

[gziolo]

Looking into it.

[gziolo]

It looks like this behavior to focus block transformer for 2 or more blocks of the same type was added with #9572. This logic isn't triggered when:

• a single block is being edited
• two or more blocks are selected but one of them has different type - in effect block transformed isn't displayed

I would argue that for consistency we should remove this behavior altogether which will solve the original issue and will bring back consistency. Any objections?

[jasmussen]

Thank you SO much for looking! This is critical path stuff.

I would argue that for consistency we should remove this behavior altogether which will solve the original issue and will bring back consistency. Any objections?

This sounds right to me. But to understand why this change was introduced, can you clarify the following a bit?

two or more blocks are selected but one of them has different type - in effect block transformed isn't displayed

So whether or not the transform button should be there, is what triggers this issue, correct?

I would say overall, that so long as you can tab (or shift tab) into the transform menu from a multi selection, it's fine to remove that behavior.

[youknowriad]

closed by #11237