-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Update Dropdown’s toggle/popover coordination to be UA-agnostic #30786
Conversation
Size Change: +112 B (0%) Total Size: 1.46 MB
ℹ️ View Unchanged
|
9f5feb8
to
4b29c65
Compare
To toggle properly it should return a single-child from renderToggle render prop. The prior use seems to be a hack around style concerns.
It was a hack to avoid toggle behavior bug in some UAs. Also, an unused classname is removed.
1ab7f99
to
4ab48b9
Compare
props.onMouseUp?.( event ); | ||
}, | ||
}; | ||
toggleElement = cloneElement( toggleElement, pressHandlers ); |
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.
Clever solutions, Unfortunately, this is a breaking change in WordPress and something we can't ship just like that. Potentially we can try to detect whether we receive just a single element.
The problem though is even if it's just a single element, there's no guarantee that this element supports these props. So for me instead of doing this like that, we could potentially add these two handlers as new args
to the render callback and have the consumer add them.
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.
there's no guarantee that this element supports these props
True, one of the adjustments made in this PR was a to ButtonBlockAppender
which didn't work even though it already returned a single element.
we could potentially add these two handlers as new args to the render callback and have the consumer add them
I'm happy to polish up my draft PR #30397 which does just that.
Thank you for reviewing 🙇
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.
@youknowriad, I found a one-liner solution for this in #31170. Pinging you here for the context. It's much appreciated if you'll have a look.
Closing in favor of #30397 which still needs some work. |
The Dropdown (and DropdownMenu) components have broken toggle behavior in some browsers (notably Safari and Firefox on macOS).
To fix it I've explored alternate approaches (a couple in #30397) and this PR is my favored solution as it requires no changes to the vast majority of
Dropdown
implementors because they happen to already meet the new requirement of returning a single child from therenderToggle
callback. Only four (of the more than twenty) in core needed updates, and being rather minor, those updates have been included in this PR. Mostly they constitute slight code quality improvements.How has this been tested?
Manually in Chrome, Safari and Firefox on macOS. In the Post Editor and Site Editor, checking various instances of
Dropdown
andDropdownMenu
to verify they toggle as expected when pressing the toggle,Esc
key, and when opening modals from within (more menu). Also, running the tests.Screenshots
Before: the broken toggling of various dropdowns in Safari on macOS
dropdowns-in-safari.mp4
Types of changes
Bug fix: #29746
Breaking change: Implementors that don't return a single child from the
renderToggle
callback would exhibit broken toggle (closing) behavior in all browsers but judging by the usage in Gutenberg most implementations should already be compatible.Checklist:
*.native.js
files for terms that need renaming or removal).