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
Base Tracking Branch: Top Toolbar DOM Updates #55780
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Size Change: +264 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
jeryj
force-pushed
the
base/top-toolbar-refactor
branch
from
November 1, 2023 20:25
ad492e6
to
3ed50ec
Compare
Stores the element that had last focus from the editor when focus leaves the editor canvas
Adding the escape keypress from the navigable block tools will require forwarding the ref from the BlockTools all the way down to the NavigableToolbar.
This method requires forwarding a ref from the editor level down to the navigable toolbar so that the escape unselect shortcut can be blocked and the navigable toolbar event listener will still fire. Blocking the global escape event shouldn't be necessary, but we have a combination of a few things all combining to create a situation where: - Because the block toolbar uses createPortal to populate the block toolbar fills, we can't rely on the React event bubbling to hit the onKeyDown listener for the block toolbar - Since we can't use the React tree, we use the DOM tree which _should_ handle the event bubbling correctly from a `createPortal` element. - This bubbles via the React tree, which hits this `unselect` escape keypress before the block toolbar DOM event listener has access to it. Also, this is better than attaching it to all of the children in the block toolbar because when new items are attached to the toolbar (such as via the bubblesVirtually slots or the apply/cancel buttons when cropping an image) we can still catch the events. Otherwise, those buttons are added after the mount, and the children don't receive the listener.
I added it since it was passed in, but it is a callback and doesn't change. It was causing unnecssary rerenders that was messing with the focus position when selecting an item from a dropdown, such as when changing the heading level on a site title block.
jeryj
force-pushed
the
base/top-toolbar-refactor
branch
from
November 2, 2023 14:14
3ed50ec
to
ad87967
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DO NOT MERGE
What?
This is an ongoing working/tracking branch not intended to be merged. It's a way to give myself a way to work on the final state of #55223 / #54513 while waiting on all the refactors and related work to get merged.
I keep rebasing this one off of the PRs listed below to keep this branch "dirty" as a base branch so the final Top Toolbar DOM PR can look cleaner to review and test in the meantime. This PR contains commits from the following PRs:
Why?
Hopefully making life easier by making smaller PRs, while also allowing myself to work on a potential version of the top toolbar DOM at the same time. This means fewer large refactors within the final PR that touch hundreds of lines of codes just via a tab indent, and each of those refactors is genuinely useful on their own.
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast