-
Notifications
You must be signed in to change notification settings - Fork 432
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(core): fix issues with PT-Input PopoverModal #8021
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
No changes to documentation |
2f8c9b2
to
c68ca36
Compare
Component Testing Report Updated Dec 13, 2024 1:01 PM (UTC) ❌ Failed Tests (6) -- expand for details
|
⚡️ Editor Performance ReportUpdated Fri, 13 Dec 2024 13:01:46 GMT
Detailed information🏠 Reference resultThe performance result of
🧪 Experiment resultThe performance result of this branch
📚 Glossary
|
if (contentElement) { | ||
contentElement.querySelector('input')?.focus() | ||
} | ||
}, [contentElement]) |
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 should rather be handled by the autoFocus prop so that it works like the other Modals we use (where the first focusable element is focused, usually the close-button).
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.
That works in my testing 👍.
c68ca36
to
465db20
Compare
465db20
to
f986921
Compare
f986921
to
075fe6d
Compare
This is no longer needed after sanity-io/ui@c95c1c0
…pover Modal The PopoverModal should have the same kind of focus locking as other dialogs
075fe6d
to
5bcd296
Compare
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.
Looks good to me 🙌. I tried this in Test Studio, and it worked as you described. I added one small comment, but it's not a blocker.
contentElement.querySelector('input')?.focus() | ||
} | ||
}, [contentElement]) | ||
const handleFocusLockWhiteList = useCallback((element: 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.
Language nit: we should use a term like allowList
instead.
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.
allowList
The dependency library uses this term, so it's supposed to match that.
if (contentElement) { | ||
contentElement.querySelector('input')?.focus() | ||
} | ||
}, [contentElement]) |
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.
That works in my testing 👍.
Description
Remove the workaround for the @sanity/ui issue (which has been fixed) with the initial rendering in the wrong position. This is no longer needed and can cause problems with assertions in tests.
Implement focus locking inside the modal. The PopoverModal should have the same kind of focus locking as other dialogs
What to review
That popover modals for links inside the Portable Text Input traps focus and work as expected.
The popover modal position is correct when first opened.
Testing
Open a Portable Text Editor with a link schema type and do the review steps above.
Notes for release