Opened 12 years ago

Closed 12 years ago

#5425 closed defect (invalid)

Tooltip delay assumes connectId is visible

Reported by: tk Owned by: tk
Priority: high Milestone: 1.1
Component: Dijit Version: 1.0
Keywords: dijit.Tooltip Tooltip top left Cc: bill
Blocked By: Blocking:

Description

When you have a delay on a tooltip (to display) if during that delay the node becomes unavailable (new tab is selected in a tabContainer or display none'd? -- I know the tab test works) the timer is not stopped (how could it know really...) but when it fires, it makes no check to validate that the node its trying to open by is still available and you get stuck with Tooltips opening in the top left corner.... (and sometimes not going away w/o opening a 2nd tooltip and letting it go away naturally)

Change History (4)

comment:1 Changed 12 years ago by bill

Hi. This is supposed to work because the target node gets an onblur or mouseout event. Not sure why it isn't. Can you attach a testcase? I could try to reproduce myself but it would be better if you made the testcase.

comment:2 Changed 12 years ago by tk

Hmm I just made a test case or modified the test_TabContainer and it works fine... execpt even the stock test_TabContainer on nightly archives shows the tooltip way off to the right... Top tabContainer has a tab with a P tag that has a tooltip on it... hover over it and see...

I'll keep plugging at mine to see ifI can break a simple test case though.

comment:3 Changed 12 years ago by tk

Cc: bill added
Owner: set to tk
Status: newassigned

Bill,

I cant reproduce this, but I did trace this to a possible bug in dojo.isDescendant().

onMouseOut for tooltip sometimes has wierd target/relatedTarget values (div.anonymous-div (which doesnt really exist!?!?) and when these are passed to dojo.isDescendant() it errors and returns -1 under its "squelch" branch... this -1 will eval as a "real event" in Tooltip and not kill the display(ed|ing) tooltip.

Patching the isDescendant() to return false on all "not true" states, fixes this problem....

Now the question is... should we patch core, or patch the dijit to check more strictly for !==true or ===true so -1 wont be true?

comment:4 Changed 12 years ago by tk

Resolution: invalid
Status: assignedclosed

Closing out as invalid, since the problem was identified as being in Core. refs #5464

Note: See TracTickets for help on using tickets.