-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
List View: Account for text fields in shortcut handler #61583
Conversation
// Retain the default behavior for text fields. | ||
if ( isTextField( event.target ) ) { | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mcsf, @andrewserong, what do you think about this solution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind it, but for completeness' sake this is what my local branch looks like:
diff --git a/packages/block-editor/src/components/block-rename/modal.js b/packages/block-editor/src/components/block-rename/modal.js
index f3db0d6c362..0ca42aacad4 100644
--- a/packages/block-editor/src/components/block-rename/modal.js
+++ b/packages/block-editor/src/components/block-rename/modal.js
@@ -67,6 +67,11 @@ export default function BlockRenameModal( {
focusOnMount="firstContentElement"
aria={ { describedby: descriptionId } }
size="small"
+ onKeyDown={ function stopKeyPropagation( event ) {
+ if ( event.key === 'Backspace' || event.key === 'Delete' ) {
+ event.stopPropagation();
+ }
+ } }
>
<form
onSubmit={ ( e ) => {
with the current draft commit message:
Naive fix, just to get the ball rolling.
The rationale here is that the Modal component is the boundary that
corresponds to the user's mental modal of "UI boundary". So intercept
key presses at that boundary, preventing those events from reaching
ListViewBlock (since #61130, where this bug was introduced), where they
will cause the current block to be deleted.
Both approaches probably carry some unknowns, I'll let you follow your intuition. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also considered fixing the issue locally for the "Rename" modal, but the same issue will affect other modals (e.g., "Create pattern") with text fields.
My thought was that consumers shouldn't care how list view handles shortcuts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me
Size Change: +7 B (0%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
await editor.setPreferences( 'core', { | ||
showListViewByDefault: true, | ||
} ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just setting the preference doesn't open the list view. It needs a page refresh or manual trigger.
name: 'core/group', | ||
attributes: { content: 'First Paragraph' }, | ||
} ); | ||
await editor.insertBlock( { name: 'core/group' } ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided to just insert a group block instead of converting it.
@getdave, do we need to test a nested block, or is it okay this way?
// Check the original block name to reflected in List View. | ||
listView.getByRole( 'link', { | ||
name: 'Group', | ||
} ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just constructing a locator doesn't test anything, so the test never asserted values in the List View. This is fixed now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the ping! I agree that consumers shouldn't have to worry about the list view unexpectedly handling keyboard shortcuts, so checking that we're not in a text field does seem pretty good from that perspective.
In terms of the rename modal, would it be worth also including the change from @mcsf? Without it, if you tab over to either of the buttons within the modal and then press backspace, it'll also delete the block:
2024-05-13.13.47.46.mp4
Not a blocker to landing, though, if you want to get this fix in quickly, as it's a much less visible issue.
Thanks for the review, @andrewserong!
It's probably rare, but that would still fix an issue in the wrong place. I think we might want to ship a more general fix, though I'm not sure what for the moment. P.S. You can use shortcuts on canvas to delete a block, but it's much easier in the List View, with a single delete key. |
@mcsf, @andrewserong here's an alternative fix #61606. I only merged this one to have the fixed e2e test in place. |
What?
Fixes #61544.
PR fixes a bug when pressing Delete in modals opened from the List View was causing block deletion.
Todo
Why?
This fixes a regression introduced in #61130. The list view shortcut handler now captures events propagated from modals.
Testing Instructions
Testing Instructions for Keyboard
Same.