mantine: Uncontrolled tooltips don't appear in Chromium-based browsers when pointerType is 'pointer'

There should not be any issues, I’ll update the package to the latest version in 5.10

Yes, I also changed the package name just then to @floating-ui/react (for a couple reasons) but it has the fixes in. It should be straightforward to upgrade to that package in Mantine

@Slapbox Thanks a lot for the investigation.

what’s your mouse situation on that machine?

If you mean pointerType, Mine is hand.

can you confirm that the delay doesn’t work on your machine as well using this sandbox?

• Most of the times there is a delay of 5 seconds.
• Sometimes after leaving the mouse pointer from Button, Tooltip disappears immidiately.

pointerType can be hand 😓 ?! Maintaining a library is hard, magical values can appear out of nowhere 😄

@nmay231 No. It’s just a pure Ubuntu install on hardware.

@nmay231

CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
GPU: Intel Corporation HD Graphics 530
Linux: Ubuntu 20.04.3 LTS
Windowing system: wayland
Chrome: 107.0.5304.87 (Official Build) (64-bit)
Chromium: N/A
Electron chromium backend: N/A

Sandbox code: https://codesandbox.io/s/amazing-blackburn-ms245w?file=/src/App.tsx 
 - Not working on chrome
 - Working on Firefox

Okay, I still cannot reproduce the issue in Chrome on macos and Windows, so I cannot do much about it

@Slapbox Sure thing.

Doesn’t look like Multiple Raster Threads: Enabled is the issue, unfortunately.

@picobyte that doesn’t sound like the same issue, and I apologize for not properly updating the title and closing this. I do believe this is resolved via an upgrade of the floating-ui dependency.

In my case it was not Linux per se, but the fact that pointerType was pointer rather than mouse. In my case nothing showed, but it sounds like something is showing for you.

I’d advise opening a new issue, or otherwise updating the details here to show that this issue isn’t fixed. I will close this issue for now (as I should have long ago) because I believe this is fixed.

Ok good, we’ve corrected this already in 0.13.3, so the issue should be fixed without needing anything else changed

So we just need a PR upgrading @floating-ui/react-dom-interactions to resolve the issue on Mantine’s side?

The reason is, when mouse pointer goes on the button and leaves it (before reaching to 5 second timeout), and doing that again (actually two times enter and leave before 5 second timeout), the tooltip disappears immediately on the second leave.

Does this happen on my Sandbox (upgraded to 0.13.3)?

pen

Ok good, we’ve corrected this already in 0.13.3, so the issue should be fixed without needing anything else changed

Yeah I do think it needs to be renamed as a result. I try to keep breaking changes to a minimum, but sometimes unavoidable :\

@Slapbox I think the best way would be to convert your PR to just check for !== 'touch'. That will handle a myriad of cases we can’t possibly predict, while removing hover for touch which is really the main goal.

@rtivital @nmay231 here’s a sandbox using the example from Floating UI’s tooltip page. It works on all machines, problem or not. I think there must be some implementation issue present in the Mantine configuration that isn’t present in this minimal example: https://codesandbox.io/s/wizardly-wildflower-tl3bh0?file=/src/App.js

This is basically just a copy/paste of the code from https://floating-ui.com/docs/tooltip#usefloating-hook (but piecemeal because they don’t have all of the relevant code shown in a single codeblock) - except I disabled the line whileElementsMounted: autoUpdate to be closer to Mantine’s implementation.

With Mantine, when I set useFloating to rely directly on the outputs of useState (like below,) it didn’t fix the problem, so I think there’s some other issue in the Mantine code, which somehow is only affecting Linux. I wonder if this points to a problem in Tooltip.js or in use-tooltip.js, or elsewhere.

The floating-ui package in the repro is newer than in Mantine, but I forced Mantine to use the newest version in our project and it made no difference in the problem, so I don’t think it has anything to do with Floating UI version.

Here’s what did not work to fix the issue

function useTooltip(settings) {
  const [uncontrolledOpened, setUncontrolledOpened] = useState(false);
  // ...
  const {
    x,
    y,
    reference,
    floating,
    context,
    refs,
    update,
    placement,
     middlewareData: { arrow: { x: arrowX, y: arrowY } = {} }
  } = useFloating({
     placement: settings.position,
    open: uncontrolledOpened, // <<< Updated to use useState instead of the useCallback
    onOpenChange: setUncontrolledOpened, // <<< Updated to use useState instead of the useCallback
     middleware: [
       offset(settings.offset),
       shift({ padding: 8 }),
       flip(),
       arrow({ element: settings.arrowRef }),
       ...settings.inline ? [inline()] : []
     ]
  });
}

So we can also rule out that it has anything to do with the useCallback here: https://github.com/mantinedev/mantine/blob/539c6c6e9f078467f7037d7314926c10b040b4c1/src/mantine-core/src/Tooltip/use-tooltip.ts#L44-L53

I know it’s not much help, but I can confirm that the 4.2.12 is unaffected on the problem machine: https://codesandbox.io/s/hardcore-carlos-l62fk5

I changed the code in useTooltip.js and found that _opened is indeed always false on any problem machine.

https://github.com/mantinedev/mantine/blob/539c6c6e9f078467f7037d7314926c10b040b4c1/src/mantine-core/src/Tooltip/use-tooltip.ts#L44-L53

  const onChange = useCallback((_opened) => {
    console.warn({ _opened }) // << Added console.warn
    setUncontrolledOpened(_opened);
    if (_opened) {
      setCurrentId(uid);
    }
  }, [setCurrentId, uid]);

What I noted: Every time the tooltip is hovered, nothing is printed. When the mouse leaves the tooltip target, then it prints {_opened: false}.

Tooltips can be made to appear on the problem machines: In the debugger, pause at this line and then call setUncontrolledOpened(true).

I can confirm. None of the examples in the link below are working on the Linux Chrome browser.

https://mantine.dev/core/tooltip/

But they are working fine on Firefox.

No, still no idea

Thanks for testing @nmay231. Unfortunately it’s definitely not due to any extension as I’m able to reproduce it in Chrome and in Electron, but maybe it’s something related to GPU rendering on Linux?

I’ve been trying to test on a third machine but haven’t been able to get a Chromium browser installed yet due to some dumb bug in Manjaro.

I’ll update with further findings as I can.

@Slapbox Your sandbox works fine for me on Ubuntu 22.04 (Wayland I think?) with Chrome 104.0.5112.101. I have tried hovering/unhovering multiple times, switching focus between tabs and windows then trying again, and hovering while focused on another window.

Try opening an incognito window to see if an extension is causing the problem or something.