New tooltip layout

[denisborovikov]

Hi guys, sorry I late for the party.

I noticed that the last changes in the code base replacing mouseleave event with the calculated mouseOutside brought more bugs and edge cases than expected.

My idea is to revert changes back to mouseleave and eliminate the offset option.

Here's a rough sketch of how it might work.

We need to change our example's HTML-markup, add an additional container inside of the tooltip. The offset will be now set within the CSS. I suggest adding pointer-events: none to the arrow element by default in all cases, make it purely decorative. It shouldn't prevent user interactions with the tooltip.

Such composition let us avoid the necessity of setting delayHide for the interactive tooltips because as soon as a user moved a cursor from the reference element in the direction of the tooltip - they're already hovering the tooltip even if the cursor is over the yellow zone.

I'll try to make a PR soon.

Let me know your thoughts @mohsinulhaq @czabaj

[czabaj]

This looks great. I will sum up my understanding to assure I got it correctly - the Tooltip and the Reference will always "touch" themselves (although both will be in different stacking context) the arrow will be pointer-events: none for the cases, where the arrow overlaps the Reference element - exceeds the Tooltip boundary. This will eventually suffer if the Tooltip overlaps the Reference in non-interactive mode - the mouseleave will fire when pointer moves over the Tooltip, which'll hide the Tooltip, but when the Tooltip overlaps with Reference, disappearing Tooltip will trigger mouseenter on Reference and it will loop indefinitely - but such overlapping is very rare.

[denisborovikov]

This is correct except that the arrow element has pointer-event: none in all cases. If it overlaps the reference element - it won't trigger mouseenter on Reference. If the arrow doesn't overlap, it doesn't matter. The arrow is completely within the tooltip container.

Regarding the case when Tooltip overlaps Reference in non-interactive mode, it easily can be fixed by the end user by adding pointer-events: none to the Tooltip element itself.

I don't like the idea of taking into consideration too many edge-cases. The hook gives a lot of control to the user and I'd like to keep it this way. I don't want to add additional styles or event listeners that users cannot override.

But as an idea, we can add an attribute to the tooltip, in addition to the ones added by react-popper. Something like data-popper-interactive true/false so the user will have additional control in their CSS if required.

[denisborovikov]

Looks like the new layout doesn't resolve the issue. Seems react-popper position the tooltip so there's always or at least sometimes an overlap. Maybe it's because of the fractional pixels or rounding errors.

Here I set show/delay to 500ms to make the effect more noticeable. In some positions, the cursor alternately triggers mouseleave and mouseenter events.

Kapture.2021-03-13.at.13.16.03.mp4

We can fix it by adding pointer-events: none to the whole tooltip container in non-interactive mode but in the interactive mode this still has to be fixed.

Updated: Huh, seems it's the only fix we need to apply in order to make everything work as expected. In non-interactive mode pointer-events: none exclude the tooltip element from the interactions and fixes the flickering. In the interactive mode, additional mouseleave and mouseenter listeners added to the tooltip fix flickering as well.

[czabaj]

Yes. I came to the same resolution overnight. Using the Tooltip wrapper will solve the "gap between the Reference and the Tooltip" in interactive mode, which the mouse cursor must move over - there will be no gap. And the pointer-events: none applied to the whole Tooltip wrapper in non-interactive mode shall resolve all flickering problems.

[denisborovikov]

Here's the PR #127

[denisborovikov]

I slept a night with this idea and now I'm not sure we should introduce any breaking changes, change the tooltip layout, and so on. Our hook is flexible enough so the user can implement this change by themselves if this is their case.

The changes I wanted to introduce are actually don't require layout change. They can be implemented using :before