-
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: Respect default shortcuts in modals #62479
Conversation
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. |
Size Change: -6 B (0%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
Flaky tests detected in 6418738. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9465915441
|
I tested this in Gutenberg Playground PR, and it solves the issue. 👍 |
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.
Thank you, @t-hamano!
Switching to early return makes sense. Currently, I can’t think of a case when block shortcuts might need to be propagated from modals.
P.S. I think there’s an e2e test failure, not sure if it’s related.
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.
+1 an early return sounds good here, and this is testing well for me with each of the list view keyboard shortcuts still working nicely when focus is within the list view, and with default behaviour working within the Rename modal 👍
Thank you everyone for your reviews! |
Co-authored-by: t-hamano <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: andrewserong <[email protected]> Co-authored-by: mcsf <[email protected]> Co-authored-by: colorful-tones <[email protected]>
Co-authored-by: t-hamano <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: andrewserong <[email protected]> Co-authored-by: mcsf <[email protected]> Co-authored-by: colorful-tones <[email protected]>
Co-authored-by: t-hamano <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: andrewserong <[email protected]> Co-authored-by: mcsf <[email protected]> Co-authored-by: colorful-tones <[email protected]>
I just cherry-picked this PR to the wp/6.6-beta-3 branch to get it included in the next release: 30648f5 |
Co-authored-by: t-hamano <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: andrewserong <[email protected]> Co-authored-by: mcsf <[email protected]> Co-authored-by: colorful-tones <[email protected]>
Similar to #61606
Fixes #62478
What?
This PR will respect the default behavior when keyboard events occur in a modal.
This fixes the issue where we couldn't select all the text in modals with
Ctrl + a
, (command + a
).Why?
This is because the event matches the shortcut for selecting all blocks at this point:
gutenberg/packages/block-editor/src/components/list-view/block.js
Line 290 in 2d34e2a
How?
I initially considered adding special handling for this shortcut. But it seemed more logical to me to just respect the default shortcuts for all events that occur inside a modal.
Testing Instructions
Ctrl + a
, (command + a
) in the text field.Ctrl + a
, (command + a
) in the text field.Screenshots or screencast
2d25e154695cd6e523a41bdca46d6855.mp4