Improve code commenting around focus mount behaviour of rich text Link UI #54085
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
getdave
added
[Focus] Accessibility (a11y)
getdave
changed the title
|
Size Change: +1.24 kB (0%) Total Size: 1.51 MB
ℹ️ View Unchanged
|
getdave
force-pushed
the
fix/link-ui-focus-trap
branch
from
60e96d7 to
5791996
Compare
|
Just found a bug whereby Also if we are going to trap focus in both edit and preview modes, then we need a means for keyboard users to close the |
|
Flaky tests detected in 5791996. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6037602102
|
|
@youknowriad As this code goes way back I wonder if you recall why we set |
|
@getdave If I'm not wrong, when there's already a link in RichText and you click on the link element in the RichText you want to continue typing and not move the focus to the link popover. |
mirka
reviewed
Sep 1, 2023
| @@ -230,7 +230,7 @@ function InlineLinkUI( { | |||
| return ( | |||
| <Popover | |||
| anchor={ popoverAnchor } | |||
| focusOnMount={ focusOnMount.current } | |||
| focusOnMount={ focusOnMountWithTrap } | |||
There was a problem hiding this comment.
If this is all we need, we can basically remove this line because it's the prop's default value.
On the other hand though, it kind of seems to me like the desired behavior here is actually addingLink ? 'firstElement' : true.
Excellent context. Thank you 🙇 Screen.Capture.on.2023-09-01.at.14-02-57.mp4This is what Riad is refering to. When creating a link we want focus to jump directly into the popover because it is a dialog that contains the control to do the creation. However if you already have a link then when entering into the link format (the bit that is highlighted) you do not want to steal focus into the popover because it is informational only. Instead you want to continue typing until such time as you choose to move into the link dialog. |
getdave
changed the title
getdave
added
[Type] Code Quality
|
I've updated the PR to be focused on code quality by improving the inline comment. The objective now is that:
The focus does now seem to be behaving as I expected. I'm not sure why yesterday it didn't seem to be. Hopefully this PR leaves the code in a better place than when we found it. |
alexstine
approved these changes
Sep 3, 2023
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.
What?
Improves the documentation around why the focus on mount handling is implemented in the way it is on the Link UI popover for rich text.
Complements #54063
Why?
The code around managing focus seems unusual, especially as for most dialogs the focus should always be moved into the dialog on mount.
The comment now fully documents the code and avoid potential future regressions and also avoids relying on stakeholder knowledge.
How?
Adds comment to explain why the code is as it is.
Testing Instructions
trunk.Testing Instructions for Keyboard