Search Issue Tracker
By Design
Votes
0
Found in [Package]
built-in
Issue ID
1410854
Regression
No
MouseLeaveEvent is not triggered when destroying target
How to reproduce:
1. Open the attached project "My project.zip"
2. Enter Play Mode
3. Click the "test" button at the top of the Game view window
4. Click the "Close" button
Expected results: Tooltip is not visible
Actual results: Tooltip is visible
Reproducible with: 1.0.0-preview.17, 1.0.0-preview.18 (2020.3.32f1), 2021.2.17f1, 2022.1.0b13, 2022.2.0a8
Could not test with: 2019.4.37f1 (UI Toolkit unavailable)
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [HDRP] Assertion printed when Maximum Reflection Probe count is higher than 64 due to k_MaxCubeReflectionsOnScreen when Raytracing is enabled
- Seams are visible on the Water System when multiple tiles are used and their Surface type is set to River
- Matching Game View creates unsaved changes even though nothing to save
- AudioClips do not have path or GUID in Build Report and incorrect size is reported
- The rendered color of the preset differs from the preview color when adding a new swatch in the HDR Color Picker
Resolution Note:
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<DetachFromPanelEvent> as an additional entry point for code that react 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.