Conversation
Call the clear() function only after a mouse move has been triggered and not just after a timeout has passed. This can make longer documentation texts easier to read. Extend the clear() function timeout, so that the user has enough time to move the mouse pointer to the [doc] link.
There was a problem hiding this comment.
Wouldn't tooltip appear because of mouse move in the first place?
Movement might continue for a few pixels after the tooltip shown, triggering the event immediately anyway.
|
I agree the current situation isn't great, but I am not sure that this is a very good solution (and share @mihailik's concern). I'll think about it some more when I have time, and am open to other ideas and/or examples of other UIs that solve a similar problem. |
|
What do you think of the attached patch? It makes it so that, after 1.7 seconds, if the mouse isn't over the tooltip, it is hidden. If it is, it stays until the mouse leaves. |
|
@marijnh Thank you, this solution would work out great for our needs. |
|
The 'mouseout' event bubbles up (see MDN below), so your handler for that event will fire even if you move your mouse from one tooltip child to another. The MDN article suggests using 'mouseleave' instead. https://developer.mozilla.org/en-US/docs/Web/Events/mouseout It also could be sensible to remove the tooltip on editor losing focus and editor scrolling. |
|
Sorry, scratch that. CodeMirror.contains takes care of the mouseout for child elements. I'll add a separate pull req. for losing focus and scrolling. |
3 participants
Call the clear() function only after a mouse move has been triggered and
not just after a timeout has passed. This can make longer documentation
texts easier to read.
Extend the clear() function timeout, so that the user has enough time to
move the mouse pointer to the [doc] link.