-
Notifications
You must be signed in to change notification settings - Fork 4.6k
DataForm: autofocus first input on panel view #72322
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
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: +186 B (+0.01%) Total Size: 2.54 MB
ℹ️ View Unchanged
|
|
@jorgefilipecosta this needs a rebase. |
15dafac to
52b0553
Compare
Hi @oandregal it was rebased. |
|
Flaky tests detected in 24ad962. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19543361271
|
| // First, try to find a form input element | ||
| let formInput: HTMLElement | null = null; | ||
| if ( node instanceof Element ) { | ||
| formInput = node.querySelector< HTMLElement >( |
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.
AFAIK, the difference from this hook and the existing useFocusOnMount is that this one only considers form elements. Is there anything that prevent us from absorbing this logic into the existing hook, e.g., useFocusOnMount( 'formElements' ).
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.
No we can do useFocusOnMount( 'formElements' ), we only need to decide if it is an API we should provide or not. This version keeps the functionality private while updating useFocusOnMount makes it available to anyone.
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.
Not strong opinions, but it'd be a nice addition. I see @youknowriad and @ntsekouras were involved in that hook, so I wonder if they have thoughts.
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 will work on updating useFocusOnMount.
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.
Updating useFocusOnMount makes sense to me. I guess we don't care about having a form element, but input elements instead, right? If yes, I guess the name would be more something alongside inputElements.
I don't remember if we wanted this for other use cases like focusing the input when opening the block inserter etc.. It might be useful for other places.
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.
Yes I agree this will probably have other use cases, I named it firstInputElement to be idendtical to firstElement.
52b0553 to
555a7d8
Compare
|
I @oandregal I applied the feedback I think this is ready for another pass. |
ac39929 to
165afe4
Compare
24ad962 to
8f33637
Compare
oandregal
left a comment
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, Jorge!
3cd344a to
caa918a
Compare
| ); | ||
| } | ||
|
|
||
| function DropdownContent< Item >( { |
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.
Can we remove this component and make it inline, like the modal is? It's a small nit, not a requirement. I just like that's the same as the modal code, and everything reads easily without having to jump across into components.
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.
Yes, I will apply the change 👍
Fixes autofocus behavior in dataform panel views (dropdown and modal) to focus on the first form input field.
Problem
When opening a dataform panel view (either as a dropdown or modal), the inputs were not automatically focused. Relying on the the artifacts we had like focusOnMount flag, or useFocusOnMount did not proved to be a reliable solution because some unexpected ellements may ended focused like:
This resulted in poor user experience as users had to manually tab or click to reach the actual input field they wanted to edit.
Solution
Created a custom focus management hook
useFocusOnFormInputthat:input,select, andtextareaelements (excluding hidden/disabled)preventScroll: trueto avoid visual jumps as useFocusMount does.After
Technical Implementation
New Hook:
useFocusOnFormInputCreated a new shared hook at
packages/dataviews/src/dataform-layouts/panel/use-focus-on-form-input.tsthat follows the same pattern as WordPress'suseFocusOnMounthook:Key Features:
useRefEffectfor ref-based focus managementsetFocushelper withpreventScroll: truesetTimeout(0)to ensure components are fully rendered before focusing'input:not([type="hidden"]):not([disabled]), select:not([disabled]), textarea:not([disabled])'focus.tabbable.find()if no form inputs foundHook Structure:
Testing Instructions
Manual Testing