Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#8740 closed bug (fixed)

Tooltip: Does not hide consistently with dynamically loaded content

Reported by: dsargent@… Owned by: dsargent@…
Priority: minor Milestone: 1.11.4
Component: ui.tooltip Version: 1.9.1
Keywords: Cc:
Blocked by: Blocking:

Description

Although it's better in 1.9.1 there are still times when tooltips either get stuck open. Most examples occur when a delegated event loads data into the tooltip from AJAX and the users mouse very briefly passes over the tooltip. Would a hover intent kind of delay help this. i.e. have an option to only show the tooltip if the mouse point is over the tip for a hundred milliseconds or so. In the same scenario I've also seen it flip it's behavior after quick pass. Not hovering shows the content and hovering hides it. Usually passing the mouse over the link a couple times fixes it. I don't know if any of these are really fixable. One possible speudo fix would be to track the element the tooltip is bound to and make sure the tooltip is hidden when the element is hidden or destroyed. This was in FireFox 16.0.1

Change History (31)

comment:1 Changed 5 years ago by tj.vantoll

Owner: set to dsargent@…
Status: newpending

Thanks for taking the time to contribute to the jQuery UI project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket. To get you started, use this boilerplate: http://jsfiddle.net/ZgAqH/. Open the link and click to "Fork" (in the top menu).

comment:2 Changed 5 years ago by dsargent@…

Status: pendingnew

Sorry this took a bit, been busy. http://jsfiddle.net/BukmE/ To replicate, quickly pass the mouse pointer over the view link. After 500ms the tooltip will appear and not disappear. Closing the dialog will not make it go away either. Waving the mouse over the view link will eventually make it go away (if the 500ms timer where not there that is). Basically, if the callback function takes a little bit (in this case 500ms) it will induce the behavior. I know I'm using a hideous pause event that is straight from the devil, but that was done to invoke the behavior on a repeated basis. In the "real world" any call to an Ajax function that takes a more than a few ms will cause this. We see it repeatedly on fresh page load (no caches).

comment:3 Changed 5 years ago by dsargent@…

Update: After playing with it for a bit here's what I *think* is going on. If the callback function takes longer to respond than the users mouse is over the link, the problem occurs. Hope that helps.

comment:4 Changed 5 years ago by tj.vantoll

Status: newopen
Summary: Tooltip still does not hide consistently.Tooltip: Does not hide consistently with dynamically loaded content

Thanks, I was able to verify this. Interestingly I was able to recreate this issue on Firefox 16 and Chrome 22 on Windows 7 but I cannot get it to happen on OS X regardless of browser.

comment:5 Changed 5 years ago by Jörn Zaefferer

Need to get rid of the while-pause and replace the dialog with just triggering focus programmatically. That would make it easier to track down the actual issue.

comment:6 Changed 5 years ago by tj.vantoll

Played with this one a bit, the bug actually looks to be related to the setting of focus. Dialog does this automatically, but if I programmatically set focus on an element AND use a delay in the content option the tooltip never goes away - http://jsfiddle.net/tj_vantoll/zGkxX/. If the content option is simply a static value the bug is not present - http://jsfiddle.net/tj_vantoll/P4JWN/.

comment:7 Changed 5 years ago by Jörn Zaefferer

Looks like programmatic focus matches the 'focusin' event, but the event.type is actually 'focus'. Seems like a bug in core to me, but we can work around it for now: https://gist.github.com/19cd921fed1eb358dc0a

If that's okay, it also needs a unit test.

comment:8 Changed 5 years ago by Scott González

Resolution: fixed
Status: openclosed

Tooltip: Handle synthetic focusin events. Fixes #8740 - Tooltip: Does not hide consistently with dynamically loaded content.

Changeset: 1b503a237e1dc47739a8a451debbc86e169851e3

comment:9 Changed 5 years ago by Scott González

Tooltip: Handle synthetic focusin events. Fixes #8740 - Tooltip: Does not hide consistently with dynamically loaded content. (cherry picked from commit 1b503a237e1dc47739a8a451debbc86e169851e3)

Changeset: f4ce4d309c6384ccda68065bbbee5a4404385503

comment:10 Changed 5 years ago by Scott González

Milestone: 1.10.01.9.2

comment:11 Changed 5 years ago by dsargent@…

I may be missing something but this does not look fixed to me. http://jsfiddle.net/PkJrP/ Same code as my original above but changed the library to 1.9.2 Same problem. Quick hover over the link and the tooltop will stay open.

comment:12 Changed 5 years ago by tj.vantoll

Milestone: 1.9.21.10.0
Resolution: fixed
Status: closedreopened

It looks like the bug caused by explicitly setting focus was fixed in 1.9.2; I no longer see that problem. However there's definitely something still off here.

Test case against master - http://jsfiddle.net/tj_vantoll/Z2R43/. In this one I am no longer explicitly setting focus and I was able to recreate the issue on Chrome 23 and Firefox 16 on OS X).

To recreate: 1) Hover over the link with the cursor. 2) Leave the link with your cursor before the tooltip is fully faded in. 3) Occasionally the tooltip will not disappear and be stuck displaying indefinitely.

You might have to do it a few times to see the issue. After playing with this for a few minutes I was able to get the issue to happen fairly consistently.

comment:13 Changed 5 years ago by tj.vantoll

Milestone: 1.10.0none

comment:14 Changed 5 years ago by EliW

Just wanted to confirm that I had the same issue just recently. Ajax based content endpoints, and if you moved on/off it quickly it stayed forever.

I temporarily fixed it, by adding some .mouseenter .mouseleave code to track the hover status, and then upon 'open', it checks if the mouse is still hovering or not, and only allows the open if so. Otherwise it issues a .close() to shut it down immediately. Hacked, but solves the issue.

comment:15 Changed 4 years ago by avatarus

Same issue with me. Any luck finding solution?

comment:16 Changed 4 years ago by tj.vantoll

#9198 is a duplicate of this ticket.

comment:17 Changed 4 years ago by tj.vantoll

Test case from lokicat in #9198: http://jsfiddle.net/tj_vantoll/nqJBf/

comment:18 in reply to:  17 Changed 4 years ago by jonaslewin

Thanks tj.vantoll. The lokicat fiddle describes the problem exactly. Just hope that it will be fixed soon.

comment:19 Changed 4 years ago by mziech

I think the event handlers for events closing the tooltip are registered too late. I submitted a pull with suggested fix.

https://github.com/mziech/jquery-ui/commit/3b2c55d7136615a2802241225abf060c9a1bf795

comment:20 Changed 4 years ago by ka3yc

I think, i've found a workaround, until this bug is fixed :)

http://jsfiddle.net/hkuFE/2/

comment:21 in reply to:  19 Changed 4 years ago by zigshanklin

Replying to mziech:

I think the event handlers for events closing the tooltip are registered too late. I submitted a pull with suggested fix.

https://github.com/mziech/jquery-ui/commit/3b2c55d7136615a2802241225abf060c9a1bf795

Thanks Marco for your patch. It fixed my problem. This needs to be in a release. Has it fallen off the radar? It's a serious bug for anyone using context functions.

comment:22 Changed 4 years ago by foodbaby

Thanks for the patch Marco - it works! Still waiting for the pull request to be merged: https://github.com/jquery/jquery-ui/pull/1053

comment:23 Changed 3 years ago by shivamtandon24

Still having the same issue while using the tooltip in a grid. The tooltip does not close if the movement of the mouse is swift if the data volume in the grid is high. I am currently using IE8 and 1.10.2 version of jquery UI.

Last edited 3 years ago by shivamtandon24 (previous) (diff)

comment:24 Changed 3 years ago by totszwai

Also encountered this problem, but mine is produced slightly differently. I have some drag-and-droppable elements, the droppable element has title (so it will trigger tooltip) when i drag an element on top of a droppable element, tooltip will show and when i release my mouse, another new tooltip will gets created, the previous tooltip will be stuck.

My workaround is much simpler and works wonder for simple tooltip.

open: function(event, ui) {
    $(ui.tooltip).siblings(".tooltip").remove();
}

Basically just remove any other stuck tooltips. HTH

Last edited 3 years ago by totszwai (previous) (diff)

comment:25 in reply to:  23 Changed 3 years ago by lotjuh

Replying to shivamtandon24:

Still having the same issue while using the tooltip in a grid. The tooltip does not close if the movement of the mouse is swift if the data volume in the grid is high. I am currently using IE8 and 1.10.2 version of jquery UI.

Can you try my fix? https://github.com/jquery/jquery-ui/pull/1272

comment:26 in reply to:  22 Changed 3 years ago by TheDude

Replying to foodbaby:

Thanks for the patch Marco - it works! Still waiting for the pull request to be merged: https://github.com/jquery/jquery-ui/pull/1053

This fixed the issue for me (jQ 1.11.1 & jQ UI 1.10.4). I manually applied the patch. Thank goodness and thank you!

comment:27 in reply to:  24 Changed 3 years ago by bugtester

Replying to totszwai:

My workaround is much simpler and works wonder for simple tooltip.

open: function(event, ui) {
    $(ui.tooltip).siblings(".tooltip").remove();
}

Working fine with ".ui-tooltip" (instead ".tooltip") as selctor. Thank you!

I hope a fix coming soon. I use jQuery-UI 1.11.1

comment:28 Changed 3 years ago by Marco Ziech

Resolution: fixed
Status: reopenedclosed

Tooltip: Register event handlers before content is loaded

Fixes #8740 Closes gh-1053 Closes gh-1456

Changeset: c4e367bb31c21d7c8b2701c626a92a2f13be5af4

comment:29 Changed 3 years ago by Scott González

Milestone: none1.12.0

comment:30 Changed 3 years ago by Marco Ziech

Tooltip: Register event handlers before content is loaded

Fixes #8740 Closes gh-1053 Closes gh-1456 (cherry picked from commit c4e367bb31c21d7c8b2701c626a92a2f13be5af4)

Changeset: 88291ffc4d6a5f4762ae65e42de607f5588101dd

comment:31 Changed 3 years ago by Scott González

Milestone: 1.12.01.11.4
Note: See TracTickets for help on using tickets.