fix(tooltip): dismiss floating tooltip when its trigger is hidden without pointer events

[j15z]

Summary

• Markdown editor table toolbar tooltips (e.g. "Delete column") lingered on screen after the toolbar hid on Cmd+A or after deleting a row/table — tiptap hides its bubble menu via visibility: hidden with no pointer movement, and Safari/WebKit never re-fires pointerleave when the hovered element is CSS-hidden, so the portaled tooltip never dismissed
• Fixed in the emcn tooltip itself so every toolbar/menu tooltip gets it: while a tooltip is shown, a 150ms watcher re-verifies its trigger and dismisses once the trigger is unmounted or no longer visibly rendered (checkVisibility(), computed-visibility fallback for Safari < 17.4 / jsdom)

Type of Change

• Bug fix

Testing

• New jsdom tests for the watcher: hidden trigger, unmounted trigger, normal pointer-leave, and no false dismissal while the trigger stays visible; full emcn suite passes, type-check clean
• Reproduced the lingering tooltip pre-fix in Playwright WebKit against a real-browser harness of the bubble-menu structure; post-fix it dismisses in both WebKit and Chromium

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 7, 2026 12:36am

[cursor]

PR Summary

Low Risk
Scoped to emcn tooltip dismiss logic with new tests; no auth, data, or API surface changes beyond fixing stuck UI overlays.

Overview
Fixes lingering floating tooltips when a trigger is hidden or removed by script or keyboard (e.g. tiptap hiding a bubble menu with visibility: hidden on Cmd+A) without firing pointerleave.

While a tooltip is visible, useFloatingTooltip now tracks the trigger in a ref and runs a 150ms interval that calls isVisiblyRendered (checkVisibility when supported, computed-style fallback for Safari/jsdom) and dismisses if the trigger is disconnected, CSS-hidden, or under display: none. hide/reset were moved to stable callbacks and pointer/focus handlers update the trigger ref.

Adds jsdom tests for the watcher (visible trigger, hidden/unmounted trigger, ancestor hidden, pointer leave).

^{Reviewed by Cursor Bugbot for commit 0edcfb5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

The PR fixes floating tooltips that linger after their trigger becomes hidden or unmounted without generating a pointer event.

• Tracks the active tooltip trigger and periodically checks whether it remains connected and visibly rendered.
• Handles inherited visibility and display: none on either the trigger or its ancestors in environments without checkVisibility().
• Adds jsdom coverage for hidden, unmounted, still-visible, and pointer-leave states.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the fallback now checks computed display across the trigger’s ancestor chain, and the tests exercise both direct and ancestor display-none cases.

Important Files Changed

Filename	Overview
packages/emcn/src/components/tooltip/tooltip.tsx	Adds active-trigger tracking and a visibility watcher; the revised fallback resolves the previously reported direct and ancestor display: none cases.
packages/emcn/src/components/tooltip/tooltip.test.tsx	Adds focused fallback-path coverage for hidden and removed triggers without introducing a remaining behavioral defect related to the previous thread.

_{Reviews (2): Last reviewed commit: "fix(tooltip): catch display: none trigge..." | Re-trigger Greptile}

[j15z]

@greptile

[j15z]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 0edcfb5. Configure here.}