Fix stray tooltips after touch drawer dismissal - #3419
Merged
ymichael merged 2 commits intoSep 10, 2026
Merged
Conversation
The sidebar footer disclosure trigger (Provider usage) left a stray tooltip on screen after a touch journey: opening the disclosure, closing it via the header chevron, then opening and dismissing the sidebar More drawer. Event capture in a coarse-pointer browser session showed the drawer's focus restoration landing on the footer trigger and Radix opening the tooltip 2ms later, with no hover to close it again. The footer's own tooltip suppression had already been cleared by the blur when the drawer took focus. Radix only guards focus-opened tooltips with an isPointerDown check, which does not hold on touch because focus arrives after pointerup. Compose an onFocus handler on the shared TooltipTrigger that prevents the open unless the last input modality was the keyboard, reusing the existing isLastInputKeyboard tracker. Mouse hover and keyboard focus tooltips are unaffected, and focus restoration itself is untouched. Existing tests that used a bare focus event to assert tooltip copy now go through a focusWithKeyboard helper, which is what they meant. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The shared TooltipTrigger modality guard covers every pointer and touch path that suppressedTooltipKey existed to handle, so the footer no longer needs its own flag, the blur/pointerleave handlers that drained it, or the two props threading it through PluginSidebarFooterItems and SidebarFooterItemButton. The state itself stays, renamed to restoreFocusKey: its load-bearing job was never tooltip suppression but telling the layout effect which trigger to focus after the disclosure closes. The old name described the caller, not the value. Closing the disclosure with the keyboard now shows the trigger's tooltip on the restored focus, which is the same thing tabbing to it does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ymichael
deleted the
bb/fix-stray-footer-tooltips-after-touch-drawer-dis-thr_jhi2cwgu29
branch
September 10, 2026 16:51
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human comments
What was wrong
Radix opens a tooltip when its trigger receives focus after its pointer-down guard has cleared. On touch, focus restoration can arrive after pointer-up; the footer-specific suppression was then cleared when the More drawer moved focus, so dismissing that drawer restored focus to the footer action and left its tooltip open without hover.
What changed
The shared tooltip trigger now composes its focus handler and allows focus-opened tooltips only when the existing input-modality tracker reports keyboard input. Mouse hover and keyboard focus still open tooltips, while touch/pointer focus restoration does not. The now-redundant footer suppression state was removed while preserving focus restoration, and the plugin registry artifact was regenerated for the shared dependency. Existing tooltip tests now use an explicit keyboard-focus helper where that is the intended interaction.
How you verified