MouseLeaveEvent not triggered when hiding target

Unity Engine
,
1

Hi,

I noticed that the MouseLeaveEvent is not triggered when its target is hidden. This is my use case:

  • Dialog with close button in the upper right corner
  • Hover over button and tooltip appears
  • Close dialog with button
  • The tooltip is still visible because the MouseLeaveEvent wasn’t triggered

Is this a bug? Or should I use a different event to hide the tooltip?

Thanks!

1 Like
2

This is possibly a bug, and it would be better to have the project and some sequence to reproduce this to answer in details. Can you report a bug in the editor with your project included and detailed step as to how to reproduce this?

Someone will investigate this and should come back to you.

3

Ok, I’ll make a sample project and file a bug report. Thanks for the reply!

4

You can listen to DetachFromPanelEvent, which should trigger when the dialog is destroyed.

5

Aha that works! Thanks! Not sure whether you would expect MouseLeaveEvent to be triggered too, I’ll report it anyways.

6

Are you using the built-in tooltip feature or some custom one?

7

I’m using a custom one. The built-in tooltip is not working at runtime, only in the editor so the built-in tooltip is not usable for our application.

8

I am currently also looking into how to make tooltips viable for runtime. Do you have any source code you are willing to share ? :slight_smile:

9

I based my code on https://github.com/plyoung/UIElements see also https://discussions.unity.com/t/796019 . I made a few small changes like adding this DetachFromPanelEvent to the TooltipManipulator.

10

I got a reply of the Unity Support fyi:
"
This is indeed by design. No events are sent to elements that aren’t part of a panel because events are tied to panels (for example there are some differences between how editor panels and runtime panels process their events).
Also, MouseLeaveEvent isn’t sent immediately when an element isn’t found under the mouse. Instead, it’s sent as part of a process of updating the element under the mouse, which happens through an event queue, and the DetachFromPanelEvent is processed earlier, with a higher priority.
We don’t want to change the order in which events are processed unless this becomes a real generalized problem that requires a larger redesign. What we recommend is to always consider using RegisterCallback as an additional entry point for code that reacts to their elements losing their hover state, or focus state, or pointer capture state, or any other on/off state that usually comes with events for both sides of the change.
It’s not impossible that this could change in the future, like MonoBehaviours receiving OnDisable before they have OnDestroy called. Simplifying edge cases in the event system is a goal for the future, but it shouldn’t hurt any forward compatibility to keep a local bool to track the status and react to DetachFromPanelEvent as an additional precaution, and it will work now as well as in the future in any case.
That said, if you have further questions, please feel free to contact us.
Thanks,
Evaldas
Customer QA Team
"