tooltip: Keep a pressed trigger's tooltip dismissed until the pointer leaves

[alex-vas]

Problem

A managed tooltip (Button::tooltip and the other components that use ManagedTooltipExt) can stay on screen for good after a click removes its trigger, for example a button that replaces the view it sits in. Only another tooltip trigger can replace it.

Steps:

1. Hover the button until its tooltip shows.
2. Click it, with the pointer moving a pixel while the button is held and again right after the release. A trackpad or mouse does this on most clicks.

The mouse-down hides the tooltip, and the pointer stays on the button the whole time. GPUI reports hover as false while the button is held. The move right after the release is dispatched to the frame that was already drawn, where the button is still hovered, so on_hover(true) fires and the tooltip is requested again. The click has already removed the button, so the next frame doesn't contain it and no hover-leave ever follows. After the show delay, the tooltip appears at the button's old bounds and stays.

Fix

A press now keeps the trigger's tooltip dismissed until the pointer actually leaves the trigger, which is how native macOS and Windows controls behave. The trigger's bounds are recorded on mouse-down in the per-window WindowState. While they are recorded, a hover-enter on that trigger requests nothing. A hover-leave clears them only when the pointer is outside the trigger, because hover also reports false while the button is held.

The change is confined to crates/component (tooltip.rs, root.rs). gpui-base is untouched.

Public API

None. The new field on WindowState is pub(crate).

Tests

Two tests in crates/component/src/tooltip.rs:

• clicking_a_trigger_away_does_not_leave_its_tooltip reproduces the bug. It dispatches the release and the move in one update so that no frame is drawn between them, as happens in a real event loop; the test platform otherwise draws a dirty window after every simulated event. It fails without the fix.
• a_press_dismisses_the_tooltip_until_the_pointer_leaves: after a click on a trigger that stays, the tooltip doesn't come back while the pointer stays on it, and does come back after the pointer leaves and returns.

cargo test -p gpui-component --lib passes (667 tests), and cargo clippy -p gpui-component --all-targets -- --deny warnings and cargo fmt --check are clean.

Found in an application built on gpui-kit 0.6.6, where the bug was reproduced with real OS mouse events. The code is the same in 0.7.x and on main.

🤖 Generated with Claude Code

https://claude.ai/code/session_019wKm1jXcvgRzuLoXfj1jMf

[madcodelife]

Thanks.