Fix: Tooltip captures click, blocking intent#77415
Fix: Tooltip captures click, blocking intent#77415DarkMatter-999 wants to merge 3 commits intoWordPress:trunkfrom
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. |
| overflowPadding={ 0.5 } | ||
| store={ tooltipStore } | ||
| disablePointerEventsOnApproach={ false } | ||
| wrapperProps={ { style: { pointerEvents: 'none' } } } |
There was a problem hiding this comment.
Could this be moved to packages/components/src/tooltip/style.scss ?
There was a problem hiding this comment.
Pull request overview
Updates the @wordpress/components Tooltip so it behaves more like native OS tooltips by not intercepting pointer interactions, preventing tooltips from blocking clicks on nearby UI.
Changes:
- Configure
Ariakit.Tooltipto avoid pointer-event locking behavior and make the tooltip wrapper transparent to pointer events. - Add a changelog entry documenting the bug fix.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/components/src/tooltip/index.tsx | Makes tooltip wrapper click-through via Ariakit tooltip props and pointerEvents: 'none'. |
| packages/components/CHANGELOG.md | Documents the Tooltip pointer-event bug fix in Unreleased notes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| disablePointerEventsOnApproach={ false } | ||
| wrapperProps={ { style: { pointerEvents: 'none' } } } |
There was a problem hiding this comment.
New behavior (making tooltips click-through) isn’t currently covered by unit tests. Since this change is implemented via Ariakit props + pointerEvents: 'none', please add a Tooltip test that asserts the rendered tooltip wrapper (or tooltip element, depending on Ariakit’s DOM structure) has pointer-events: none (or otherwise verifies clicks aren’t intercepted) to prevent regressions.
There was a problem hiding this comment.
I'm afraid we won't be able to test this in unit tests with the current jsdom-based setup
|
One question though. In the case in the video for example, wouldn't the straightforward fix be to alter the tooltip position to |
|
Hi @mirka, As noted in this comment, vertically stacked controls, like the move up/down block buttons would still face this problem, as a tooltip for one will naturally overlap the adjacent button. From my perspective, tooltips should be purely informational and shouldn't act as a physical barrier to the interface, so making them "click-through" feels like a more robust way to ensure they never interfere with a user's intent. That being said, I'd love to hear your thoughts, are there any other solutions you can think of that might fix this more effectively? 
|
|
@DarkMatter-999 in the new examlpe you showed, the issue could be avoided if the "move up" tooltip was anchored on top of the "arrow up" button. While I understand your point, I tend to agree with @mirka and I think that we should apply the proposed changes to We could open dedicated PRs to tweak Tooltip anchoring for the site logo/home button, the block mover in the block toolbar, and any other instance. |
|
Hi @ciampo, <Button
__next40pxDefaultSize
className={ classes }
href={ buttonHref }
label={ buttonLabel }
showTooltip={ showTooltip }
- tooltipPosition="middle right"
+ tooltipPosition="bottom"
>Once you confirm you'd prefer this approach, I can close this PR and open a new one (or simply pivot this PR) to address those specific positioning fixes. This is how it looks afterwards: 
cc: @mirka |
|
@DarkMatter-999 yes, let's go with this approach. We can open 2 separate PRs:
Make sure you tag us as reviewers, happy to help there. |
What?
Closes #73785
Prevents tooltip from capturing pointer events, allowing clicks to pass through to elements beneath it.
Why?
When hovering over an element that triggers a tooltip, the tooltip could physically overlap other UI elements. Clicking in that area would be captured by the tooltip rather than reaching the intended element below, unlike native OS tooltips, which are always transparent to pointer interaction.
How?
Two props are added to
<Ariakit.Tooltip>:disablePointerEventsOnApproach={false}- disables the hover-intent pointer lock, so surrounding elements remain interactive while the tooltip is visible.wrapperProps={{ style: { pointerEvents: 'none' } }}- makes the tooltip wrapper element transparent to pointer events, so any click passes through directly to the element below.Together these replicate how OS-native tooltips behave: purely visual, never intercepting mouse interaction.
Testing Instructions
Screenshots or screencast
Before:
tooltip-hover.mov
After:
tooltip-fix.mov
Use of AI Tools
Claude Sonnet 4.6 was used to help analyze the Ariakit API, and draft this PR description.