-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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 error from popover scroll hook #69479
base: trunk
Are you sure you want to change the base?
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: +10 B (0%) Total Size: 1.84 MB
ℹ️ View Unchanged
|
Flaky tests detected in 954709d. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/13703098421
|
What, why & how
Follow up to #68075 which fixed the ability to scroll “through” popovers but also introduced this error. The error wasn’t there in 6.7 (despite the feature being broken) so I’ve added the label for backporting to 6.8.
A simple fix to avoid errors logged in the console. This makes the
usePopoverScroll
hook return null in case itscontentRef
parameter is falsy.Testing Instructions
Demonstration of errors this fixes
popover-wheel-errors.mp4
Note about potential redundant execution
The instances that surface this error are curious because
usePopoverScroll
is being called byBlockPopover
which is being rendered into a slot that already callsusePopoverScroll
. This creates the potential to add twowheel
event listeners. Currently that doesn’t happen because__unstableContentRef
isn’t provided (and that’s why it errors currently). This doesn’t seem too concerning anyway since even if the "wheel" listener were doubled up it would probably just make scrolling "through" the popover go twice as fast. It’s also unlikely that first-party popovers such as these will ever be providing__unstableContentRef
and the publicBlockPopover
doesn’t support that prop. I’m noting this because it feels a little haphazard. There are various ways that we could safeguard against this but I decided against proposing anything more than this minimal change for now.