alessandro-newzoo
commented
1 year ago Yes, I can confirm this is indeed an issue, at least with programmatically/dynamically generated tooltips.
However, thanks to your workaround, I figured that the setTimeout() just needs to bee higher than the actual animation time, then in this case you can also keep the animation on.
For example, if you set your animation's duration to 200 , and your timeout on instance.show()to 201, then it will work perfectly (well, minus the annoying 200ms delay on click).
Bug description
Tippy keeps opening the tooltip at the same position if I open it continuously at various places in an element.
I would expect
followCursor: 'initial'to use the cursor position at the time the tooltip is opened - especially programatically. The "initial" cursor position is however used across multiple "openings" of the tooltip until it is "fully" closed.Manually hiding the instance first doesn't help. It is probably related to this other issue I noticed: A related bug (probably same underlying cause?) can be reproduced if one uses the
trigger: 'click'instead and clicks very fast around the canvas. If the following click happens before the previous fade-out animation finishes then it sticks to the old position. If the click happens after the fade-out animation finishes then it appears at the new position.My hope is that this behavior can be changed so that the "stickiness" is only enforced as long as the tooltip is 100% visible and that it invalidates the moment the tooltip is about to close. (It should still stay at it's position until fade-out completes)
Reproduction
See the codepen link: CodePen link: https://codepen.io/atomiks/pen/yvwQyZ
Workaround
Only workaround I have found so far is to completely disable the animation (setting it to
null) and adding a minuscule delay before opening the tooltip: https://codepen.io/RiggsDK/pen/jOzgRbq