[tooltip] Bring mobile support back?

[oliviertassinari]

Steps to reproduce

Link to live example: (required)

Steps:

1. https://master--base-ui.netlify.app/base-ui/react-tooltip/

Current behavior

No response

Expected behavior

Worked like in https://mui.com/material-ui/react-tooltip/

Also missing those tests: https://github.com/mui/material-ui/blob/eea5079a00bedb68e27f22b7f94d9a71cc97ee1e/packages/mui-material/src/Tooltip/Tooltip.test.js#L404

Context

• [tooltip] Change default of Tooltip position to "top" (at least for touch devices) #558
• Show tooltip on touch devices adobe/react-spectrum#1136

Your environment

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Search keywords: -

[atomiks]

Tooltips intentionally don't work on touch devices in the new Base UI. Hoverable popovers (for "infotips"/contextual help) are a valid pattern though, and should be used instead when the trigger's only purpose is to show the "tooltip" (infotip for more correct terminology). If the trigger performs an action, then it's impossible for a tooltip to be attached in a valid way for touch input. They're inherently secondary in nature.

[oliviertassinari]

Tooltips intentionally don't work on touch devices in the new Base UI.

Ok, turning this into a waiting for upvotes issue then.

[oliviertassinari]

I faced a pain today that seems to be a strong motive for the need to bring back tooltip support for touch devices.

I was on my phone, and as usual, I have the desktop mode enabled (nowadays, I almost never use the mobile web version of websites on my phone, most of the time it has: /2 features, a different UI organization making me so lost on them, has everything too big).

• On Ashby, I wanted to understand what this icon was for: https://app.ashbyhq.com/admin/custom-tracked-links/6efb2ea4-7a66-4046-9e4f-656a82a23053, to fix the application source association
  
  It's a Radix Primitive Tooltip

  

  I painful managed to see the content of the tooltip. I needed to toggle the focus state on the element alternating taps between two focusable elements, which would show the tooltip for about 200ms. Then I needed to do a screenshot at the right time. After 6-8 attempts, I got the screenshot at the right time and I could read it. Pain.

• On Skuad. I wanted to change the primary email address to get less spam, to delegate those to the people's team. https://pay.skuad.io/account-settings?tab=userDetails

it uses the MUI Base Tooltip, it simply worked.

[atomiks]

Those are hoverable popovers (<Popover.Root openOnHover> aka infotips) not tooltips. We already support that use case, and use it for the info descriptions on the docs. On the old docs we had a callout about the difference between infotips and tooltips - we need to add an example back to highlight why they're different

[oliviertassinari]

@atomiks As I understand the problem, it's about the tooltip component's default behavior (independently from the popover). When end-users go to a page that has a tooltip e.g. https://base-ui.com/react/components/tooltip with desktop mode enabled, they can't show the tooltip information.

[atomiks]

It seems like that's more of a documentation issue because the modality of user input (touch vs hoverable pointer/mouse) is what determines if the tooltip shows or not, regardless of desktop view etc. When the docs first launched, I did think that even for normal touch users we might want to add a callout about it not being able to appear if you're using touch input, and to consider alternatives instead