-
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
Fix navigate regions shortcuts on the back button WP logo slot #63611
Conversation
Size Change: -266 B (-0.02%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
f4a78c5
to
3be09fa
Compare
Flaky tests detected in c67cad4. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10961486395
|
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. |
@afercia, do you mind rebasing the branch and resolving merge conflicts? |
3be09fa
to
b1c9676
Compare
@Mamaduka rebased 👍🏻 |
b1c9676
to
dfb5f6d
Compare
@WordPress/gutenberg-core I'd appreciate a review. This fixes a regression that is important enough to be fixed in the next WordPress releae. thanks. |
In my testing, moving the keyboard shortcut event up in the tree has an added bonus. It makes the keyboard shortcut work also from the metaboxes area. Apparently, it didn't ever work from the metaboxes area. It works now which is even more important after #64351 I will update the test instructions. |
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.
This tests well for me in all the affected editors. Code-wise, I like it. The key thing it seems to me is that InterfaceSkeleton
has a breaking change. Before this it applied region navigation by default and now it doesn’t (nor has the capability to do so). I think this is acceptable given that any plugins consuming InterfaceSkeleton
aren’t going to experience breakage unless they upgrade their @wordpress/interface
dependency. This is because the package isn’t exposed on the wp
global; i.e. plugins using components from the package are bundling them into their build so they control the version.
A "breaking" changelog entry and dev note seem warranted. Other than that, this looks 🚢 shape to me.
@stokesman thanks for looking into this. Please do feel free to go ahead with the changelog entry. As a native English speaker I guess you're a better fit to do that 🙏🏻 |
c67cad4
to
0e87a88
Compare
@afercia @stokesman I noticed this was targetted for 6.7 but hadn't been merged. I've taken the liberty of rebasing it to resolve conflicts. In my testing based on the PR instructions this still works as expected but I'd appreciate you verifying before we look to merge 🙇 |
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 tested it and it seemed to still work fine 💯!
My only concern is whether we want to introduce a breaking change (enableRegionNavigation
) at this stage? Is there a way to gracefully handle backward compatibility? Never mind if this is a non-issue!
I can't remember the details about Anyways, I would like to remind everyone this is a regression and it should be fixed for the release. |
That prop is removed from two places:
It seems possible to not break |
I wasn't aware that the |
Given the breaking change a dev note seems like a proper thing so I added the label. Though, still the WP release won’t force the upgrade/breakage so I’m not totally sure it’s required. |
Thanks everyone for the in depth feedback. Is it OK to everyone I push the green button? Cc @youknowriad |
Go for it. Thanks all :) |
There was a conflict while trying to cherry-pick the commit to the wp/6.7 branch. Please resolve the conflict manually and create a PR to the wp/6.7 branch. PRs to wp/6.7 are similar to PRs to trunk, but you should base your PR on the wp/6.7 branch instead of trunk.
|
Looks like the conflict when cherry picking this to Shall I just follow the instructions and move the entry under the |
I would think it‘s better to put under the |
I'm not sure if there is a documented official process but this is what #65905 did. Here's the original PR that one was a manual backport to the 6.7 branch for. |
* Avoid to pass unnecessary props to useNavigateRegions. * Remove bubblesVirtually from WP logo slot. * Restore bubblesVirtually. * Move useNavigateRegions to an outermost ancestor. * Remove no longer used enableRegionNavigation prop. * Add changelog entry --------- Co-authored-by: afercia <[email protected]> Co-authored-by: stokesman <[email protected]> Co-authored-by: kevin940726 <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: youknowriad <[email protected]>
Thanks all. I created #65971 for the backport. |
* Avoid to pass unnecessary props to useNavigateRegions. * Remove bubblesVirtually from WP logo slot. * Restore bubblesVirtually. * Move useNavigateRegions to an outermost ancestor. * Remove no longer used enableRegionNavigation prop. * Add changelog entry --------- Co-authored-by: afercia <[email protected]> Co-authored-by: stokesman <[email protected]> Co-authored-by: kevin940726 <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: youknowriad <[email protected]>
* Avoid to pass unnecessary props to useNavigateRegions. * Remove bubblesVirtually from WP logo slot. * Restore bubblesVirtually. * Move useNavigateRegions to an outermost ancestor. * Remove no longer used enableRegionNavigation prop. * Add changelog entry --------- Co-authored-by: afercia <[email protected]> Co-authored-by: stokesman <[email protected]> Co-authored-by: kevin940726 <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: youknowriad <[email protected]>
…ress#63611) * Avoid to pass unnecessary props to useNavigateRegions. * Remove bubblesVirtually from WP logo slot. * Restore bubblesVirtually. * Move useNavigateRegions to an outermost ancestor. * Remove no longer used enableRegionNavigation prop. * Add changelog entry --------- Co-authored-by: afercia <[email protected]> Co-authored-by: stokesman <[email protected]> Co-authored-by: kevin940726 <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: youknowriad <[email protected]>
Fixes #63552
What?
The navigate regions keyboard shortcut doesn't work in the Post Editor when focus is on the WP Logo.
The WP logo now uses a Slot with the
bubblesVirtually
prop. That means events 'bubble' up the React hierarchy tree which may be different from the DOM tree. This may be triggered by any other slot implementation added in the future so it would be best to find a solit way to make sure navigate regions works in any case.This works in the Site editor but it doesn't in the Post editor. It took me a while to understand how the different React components hierarchy impacts this feature.
In the Site editor:
It works because
useNavigateRegions
is used on the edit-site Layout component. This component contains basically everything so that the Slots are inside the Layout in the React hierarchy.In the Post editor
It does not work because
useNavigateRegions
is used on theInterfaceSkeleton
component. However, the WP logoBackButton
is actually inside the Layout (edit-post package) > Editor (editor package) component, which thenuses EditorInterface which in turn uses InterfaceSkeleton.Similar hierarchy in the Widgets editor.
Basically, to make sure the navigate regions shortcut works in all editors regardless of where any Slot is used, there is the need to make sure
useNavigateRegions
is used on the outermost component of the editors.This PR tries this approach by moving the usage of
useNavigateRegions
up high in the components hierarchy to a couple ew div elements. If it turns to work well, maybe it would be worth considering to abstract to a 'navigate region provider' component that can be reused where desired.Cc @youknowriad to my understanding there are a few experimental 'editor providers' in place that I guess they are meant to attach behaviors to the editor and be consolidated in the future. Would a new provider for the navigate region props and ref be a good option?
Why?
To make sure the navigate regions keyboard shortcut works from everywhere.
How?
useNavigateRegions
higher up in the components hierarchy.useNavigateRegions
already has default shortcuts.enableRegionNavigation
prop.Testing Instructions
PostsApp
experiment and test.Testing Instructions with metaboxes.
Ctrl+backtick
or alternatively (macOS) Control+Option+N.Testing Instructions for Keyboard
Screenshots or screencast