fix: enable mobile-friendly tooltip behavior (Fixes #459)

[Roaring30s]

What / Why

What changed:

• Added mobile support to ExplorerTooltip by conditionally rendering Popover on touch devices instead of Tooltip (which only supports hover)
• Added Popover.Arrow to the mobile popover to match the desktop tooltip’s visual design

Why:

• Tooltips were inaccessible on mobile devices because touch interfaces do not support hover events
• Mobile users could not access explanatory tooltip content that was only available via desktop hover

Issue

Fixes #459

Reproduction + Verification

Before:

• On a mobile device, tap on any element with a tooltip (e.g., question mark icons next to stats)
• Tooltip does not appear because hover events don’t exist on touch devices
• Users cannot access explanatory tooltip content

After:

• On a mobile device, tap on any element with a tooltip
• A popover appears with the same content and styling as the desktop tooltip
• Tapping outside the popover or tapping the trigger again closes it

Verified:

• Tested on a mobile device simulator and confirmed the popover appears on tap with matching styling (background color, arrow, no white border)
• Verified that desktop hover behavior remains unchanged and works as before

Breaking / Risk / Rollout

No breaking changes. This is a backward-compatible enhancement.

Desktop:

• Hover behavior remains unchanged
• Existing tooltip interactions continue to work as before

Mobile:

• Adds new tap-to-open functionality (tooltips were previously inaccessible)
• Uses Popover from the Radix UI family for consistent behavior and styling

Risk assessment:

• Low risk: Change is isolated to the ExplorerTooltip component
• Uses conditional rendering based on device detection
• Leverages Radix UI primitives from the same library family as Tooltip

Edge cases handled:

• Respects parent-controlled open prop when provided
• Maintains onOpenChange callback functionality
• Preserves multiline variant styling
• Works with all existing tooltip usage across the codebase

[vercel]

@Roaring30s is attempting to deploy a commit to the Livepeer Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
explorer-arbitrum-one	Ready	Preview, Comment	Jan 9, 2026 4:47am

[rickstaa]

@Roaring30s thanks for your contribution! Just checked the preview. This is extremely valuable to the project. 🙏 Looks like some lining errors but after those are fixed @ECWireless can review and merge it in.

[Roaring30s]

@rickstaa Ill get those linting errors addressed.

[Roaring30s]

@ECWireless linting error fixed. Should be ready for review.

[ECWireless]

Looks nearly good to me. Although when I test the preview on Chrome in an iPhone, I get this overflow cutoff:

I'm not positive this would fix it, but could try wrapping <RadixPopoverContentStyled> in <RadixPopover.Portal>

[Roaring30s]

@ECWireless Good catch. Ill get this fixed today. Thanks for the review and feedback.

[Roaring30s]

@ECWireless I added your suggestion. I also tried on Chrome with an iPhone to see if I could get that exact same error and I didn't see it. I will share my screenshot below to what I saw clicking on the same tooltip.

Here is the AI summary to aid in your review:

Component Architecture Rationale

Separated MobileTooltip and DesktopTooltip into separate components to improve maintainability, testability, and code organization:

Note: ExplorerTooltip was becoming too cluttered with the hook logic and event listeners needed to fix the mobile tooltip bug of it not disappearing when someone would scroll or do other touch events on mobile.

1. Testability: Each component can be tested independently with platform-specific behavior (touch vs hover) without conditional logic
2. Separation of Concerns: Mobile and desktop logic are isolated, making each component easier to understand and modify
3. Future Extensibility: Easier to add platform-specific features (e.g., haptic feedback on mobile, keyboard shortcuts on desktop) without affecting the other
4. Code Clarity: Each component focuses on a single responsibility, reducing cognitive load when reading/maintaining code
5. Type Safety: Each component can have platform-specific prop types while sharing a common base interface via types.ts

Implementation Details

Mobile Tooltip Improvements:

1. Radix Portal Implementation: Wrapped RadixPopoverContentStyled in <RadixPopover.Portal> to render the popover at the document body level, preventing overflow clipping from parent containers. This fixes the issue where tooltips were being cut off in scrollable containers.

2. Touch-to-Dismiss on Scroll: Implemented touch event handlers that detect finger movement (>5px threshold) and automatically close the tooltip when the user scrolls or swipes. This improves mobile UX by preventing tooltips from remaining open during navigation.

3. Callback Reference Protection: Added useRef pattern to protect against unstable onOpenChange callbacks from parent components, preventing unnecessary re-attachment of event listeners and improving performance.

These changes ensure the mobile tooltip behaves correctly in various container contexts and provides a better user experience on touch devices.

Finally,

I didn't see the point making a custom hook for all the useEffect and state management work observed in the MobileTooltips since it will be used once and strictly applies to that small component but feel free to let me know your thoughts or any suggestions. The only benefit of adding said custom hook would be too improve testability.