Moving mouse above tooltip (but leaving the original component) keeps tooltip on

[ikornienko]

Steps to reproduce:

1. Go to http://react-component.github.io/tooltip/examples/simple.html
2. Hover above trigger, then move your mouse on top of the tooltip
3. Tooltip won't disappear (user can even select and copy-paste tooltip text)

I see it can be sometimes beneficial for the UX to give user an ability to, say, click some link in the tooltip (like "Show more"). But there are cases when tooltip has no links etc. and it happens to be on top of some element which user may want to interact with, so it creates awkward situation when user moves mouse through the tooltip-ed element, trying to reach out to another element just to find him/herself hovering over the tooltip and not being able to interact with the element tooltip covers.

There are workarounds, by changing tooltip placement and increasing mouseEnterDelay to prevent it (i.e. to make sure tooltip doesn't cover any interactive elements and not appearing if mouse pointer is just "passing by"). But I believe it's a valid case to have tooltips to appear consistently (say, on top) and with 0 delay, and disappearing right away when mouse leaves the element.

What are people thoughts on it? Should it be another property (that defaults to the existing behavior)?

[egoarka]

I did not notice something weird, works as expected

[ikornienko]

@egoarka as an illustration see this behavior, where we can assume user moves mouse pointer to reach out to "offset Y" input box, but on its way it crosses "trigger" area, and therefore the corresponding input is blocked by an appeared tooltip.

What I'm looking for is an option to have a behavior as, say, Chrome has (as well as the majority of apps) with tooltip disappearing once mouse pointer leaves the "tooltip'ed" element.

[egoarka]

@ikornienko actually this is not hard to implement over Tooltip itself https://codesandbox.io/s/olxrrlplk9

[ikornienko]

Thanks for sharing the code snippet, @egoarka ! Absolutely agree, the great flexibility of rc-tooltip (thanks to creators and maintainers of it!) allows to achieve it. I definitely can do even better by creating my own Tooltip component that adds this functionality and use it for our applications. This issue can be treated as a question: if this feature request is popular, then probably it makes sense to avoid forcing users of this library to do the wrapping of Tooltip component (or implement approach you suggested), but instead add support to the library itself. Leaving to the maintainers of the library to decide.

[ErockEsquire]

@egoarka That implementation isn't ideal because now mouseEnterDelay becomes unusable, since the appearance of the tooltip is now decided by the visible state. It would require even more logic now to set up your own delay.