Tooltips in Transfer sticks to the element when scrolling

[martinkrulltott]

I'm trying to use the Transfer component with Tooltip's for the sourceoptions, through the use of a custom renderOption. However, when scrolling the tooltip sticks to the element which makes it look a bit weird (see attached clip).

tooltip.+.scrolling.mov

Can the tooltip be automatically hidden once the target element / initiator is moving on the screen?
Or how would one best handle this situation?

EDIT: I guess the main issue isn't the fact that the tooltip scrolls around (I'll let @cooper-joe be the judge of that), but at the very least the tooltip should'nt scroll outside of the sourceoptions list / area 🤔

[cooper-joe]

I guess the main issue isn't the fact that the tooltip scrolls around (I'll let @cooper-joe be the judge of that)...

For reference, the tooltip should disappear when the cursor is no longer hovering the trigger – via scrolling, moving the cursor etc. This behaviour is a bug.

[jenniferarnesen]

This may not be an answer, but we had a similar issue in Dashboards. If the click happened on an element within the element having the mouseLeave event, then the event wasn't captured. Here is how it has been handled:

https://github.com/dhis2/dashboard-app/blob/master/src/components/ControlBar/ShowMoreButton.js#L17

[amcgee]

@varl @KaiVandivier @dhis2/team-platform seems like maybe something like this should be done in the component itself

[varl]

Thanks for the code example, @jenniferarnesen.

[KaiVandivier]

It would be nice to trigger the tooltip closing if the component moves on the page, but I don't know how that can be detected... on the other hand, it seems like the 'onMouseOut' handler could also be triggered on scroll, which would fix Martin's issue - I'll try a few things, but in the mean time, maybe a solution like Jen's could work if it's triggered on scrolling? (which should be throttled)

[ghost]

but I don't know how that can be detected

You could use an intersection observer for that https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

[martinkrulltott]

You could use an intersection observer

Good point 👍 As showcased by this very accurate infographic from smashing magazine:

[ghost]

Similar topics have come up recently. I think exposing a generic IntersectionObserver component might be helpful in providing a building block that could help resolve issues like this. We already have such an abstraction internally in ui.

[ghost]

This was suggested assuming that there was no way to detect this with popper. But it seems there is, so in that case I'd favor using popper.

[KaiVandivier]

Small update: according to Martin, this issue is currently considered "not a deal-breaker for 2.36, but a general problem that would be worth sorting out" - I'm still playing with it, especially to see if there's a way that the Tooltip component can be improved

[KaiVandivier]

Thanks to @HendrikThePendric's suggestion, the 'hide' modifier on poppers has proved to be the right tool for the job, and here's the result:

tooltip-hide.mov

I'm interested in some feedback: (@dhis2/team-platform)

1. Should the popper hide when the reference component is partially covered (as in the demo above), or only when fully covered? Check out the demo at the bottom of the popper docs page to see the difference between 'escaped' and 'reference-hidden'
2. I think this behavior should be the default for all tooltips, but should it be configurable with props? E.g. set the tooltip to hide on partial cover/full cover/not at all

P.S. I made another solution work with Intersection Observers, but it was unnecessarily complex compared to this approach

[KaiVandivier]

related pr: dhis2/ui#484

[ghost]

Yeah if popper has an approach built in then that seems like the way to go. I think as far as configurability goes, I'd first implement it as minimally as possible. Then if the need arises we can always add extra functionality. Otherwise we might risk catering to usecases that actually don't exist with the user, or overcomplicating things.

[HendrikThePendric]

This approach seems to work really well. I have one concern though: I haven’t verified but my expectation is that the events which are ignored/ not triggered during a scroll don’t just magically fire when the scroll is done.

I hope I’m wrong, and if we do eventually end up receiving a mouseout event, then I think this hide modifier is the perfect solution.

However, if we end up never receiving the mouseout event, then I believe the tooltip will remain in the DOM until the parent unmounts and that’s not pretty. We should probably explore a solution using a scroll listener in that case. Since this problem is directly related to the page scrolling we could add an eventListener for that once the tooltip shows. When a scroll happens we can check if the scroll delta is greater than the reference element size, and if so we treat this as a mouseOut.

[KaiVandivier]

Here's a new iteration with a 'flip' behavior that I think improves the behavior when the reference element is half-showing:

• It uses an opacity change in this demo to show when new styles are applied; in the real thing, this will use visibility: hidden; to hide the tooltip when the reference is out of view
• It works with createPortal after all -- no need to change that implementation
• Tooltips are successfully removed from the DOM
• Nice and simple implementation, just using popper modifiers

tooltip-hide-flip.mov

[KaiVandivier]

Fixed in UI v6.2.1 👍

[varl]

Looks very nice, good work.