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

Fix multiselecting blocks using shift + arrow #11237

Merged
merged 3 commits into from
Oct 30, 2018

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Oct 30, 2018

closes #9848

This PR fixes multiselection (of more than one block) using shift + arrow but it also keeps the focus ono the wrapper of the first multi-selected block which allows easy access to the toolbar using Tab or Alt+F10

Testing instructions

@youknowriad youknowriad added [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release labels Oct 30, 2018
@youknowriad youknowriad added this to the 4.2 milestone Oct 30, 2018
@youknowriad youknowriad self-assigned this Oct 30, 2018
@youknowriad youknowriad requested review from jasmussen and a team October 30, 2018 09:54
Copy link
Contributor

@jasmussen jasmussen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

YAAAAY THIS fixes it!

shift select

I also dig the amount of red.

Code looks very healthy to me, but if you feel you need a sanity check might want to verify with some of the better coders out there.

Thank you!

@youknowriad
Copy link
Contributor Author

The failure is something in master and it was actually fixed already.

// When triggering a multi-selection,
// move the focus to the wrapper of the first selected block.
if ( this.props.isFirstMultiSelected && ! prevProps.isFirstMultiSelected ) {
this.wrapperNode.focus();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something which is meant to occur instead of focusTabbable? If so, why do we allow focusTabbable to occur at all? I wonder also if these redundant focus changes are announced loudly in assistive technologies.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's meant to occur instead of focusTabbable and yes focusTabbable won't occur here because the isSelected is false when the block is multiselected.

I'm not sure about the assertive technologies though, it's very tied with multi-selection, not sure how multi-selection is announced.

@@ -77,4 +77,44 @@ describe( 'Multi-block selection', () => {
await pressWithModifier( META_KEY, 'a' );
await expectMultiSelected( blocks, true );
} );

it( 'Should select/unselect multiple blocks using Shift + Arrows', async () => {
const firstBlockSelector = '[data-type="core/paragraph"]';
Copy link
Member

@gziolo gziolo Oct 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The actual issue was for 3 blocks of the same type. We should add another test :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue for me was happening no matter the type of the blocks.

@@ -314,7 +320,11 @@ export class BlockListBlock extends Component {
deleteOrInsertAfterWrapper( event ) {
const { keyCode, target } = event;

if ( target !== this.wrapperNode || this.props.isLocked ) {
if (
! this.props.isSelected ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

@@ -93,6 +93,12 @@ export class BlockListBlock extends Component {
if ( this.props.isSelected && ! prevProps.isSelected ) {
this.focusTabbable( true );
}

// When triggering a multi-selection,
// move the focus to the wrapper of the first selected block.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These comments explain what we're doing (which is pretty plainly obvious in the implementation anyways) but not why. I don't know why we're doing this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We move the focus to ensure that it is not possible to continue editing the initially selected block. This happens for all active elements that allow editing like RichText, PlainText and all form fields. This behavior ensures that you no longer can modify the content of the selected blocks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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