Tooltip: Expose element which triggered the tooltip inside open/close handlers

[Ult Combo]

Title says it all. There's currently no clean way (that I'm aware of) of getting a reference to the element which triggered the tooltip.

​Test case

Also I believe this could be filed under Bug as well, seeing as the event.originalEvent.target in this case is the target of the mouseover event, while the event.target and the this reference inside the tooltipopen handler points to the document.

As this is a delegated event at its core, shouldn't document be accessible just through event.delegateTarget while this and event.target would reference the element which actually triggered the delegated tooltipopen event?

Can we have these references fixed, or a new property added to the ui object parameter or have a new parameter being passed to the tooltipopen/tooltipclose event handlers?

I believe this would be really useful for many developers out there. Thanks.

[Ult Combo]

Basically, I would like to have this ​target exposed, either through the event object or as an event handler parameter - maybe ui.element?

[Scott González]

You'll need to provide a use case. The title does not say it all...

[Ult Combo]

Well, there should be many use-cases. My specific one was performing some checks on the hovered element to display the tooltip only when the said element is overflowing horizontally, ​SO thread here.

I believe the correct way to implement such functionality would be providing an option such as a filter callback which is called as soon as a hovered/focused item triggers the tooltip, and its return value should be a boolean indicating whether the tooltip should be displayed. Though, this would most likely take a lot more of effort to implement, let alone depending on the implementation it'd mix jQuery UI tooltips with native title tooltips which would be unwanted.

Hence if I can cleanly get the reference to the hovered element inside an tooltipopen handler to perform some checks on element and call ui.tooltip.hide() depending on the condition should suffice - this way the native tooltip is not displayed and the live cycle of the UI tooltip is preserved, though it has display:none all along its live cycle.

Here's a test case with a relatively more clean way of doing the requested feature:

​test case; ​better performance version

Though I'd like to have a documented method or parameter passed to the open handler which I can safely rely on.

Other use cases include checking element's data/properties before displaying the tooltip.

[tj.vantoll]

I've implemented the exact same overflow use case described by @Ult Combo. I could also see use cases where you'd want to grab data-* attributes from the element before displaying the tooltip.

So +1 for exposing the element as a property of the ui object.

We could name it item to be consistent with the items option.

[Scott González]

If we're going to add this to the open event, we should consider whether or not to expose this in the close event as well.

[tj.vantoll]

Replying to scott.gonzalez:

If we're going to add this to the open event, we should consider whether or not to expose this in the close event as well.

We probably should so that you could undo something that you did in open. For example, add a class to the element in open and remove it in close.