Cool. I had no idea it was my fault this was happening. I’m glad I can fix it.
1 Like
Thanks for the advice! I was stuck on this for a whole month, but the whole time I had override set to true! You helped me fixed my game!
Sorry for the necropost, but it appears I’m having an issue similar to that of MouseEnter being called before MouseLeave when dragging the mouse quickly to another ui element.
Sure, I could reorient my code to a solution that does not depend on MouseLeave to be called on the first ui element before MouseEnter is called on the second ui element, but it should be expected that your mouse leaves the first element before entering the second element.
The error shown in a GIF: (Description menu not popping up)
What I get:
What I expect to get:
As a little repro as to the GIF above in a much simpler environment, you can see the attached place file and gif:
ErrorRepro.rbxl (22.0 KB)
5 Likes
I’ve not had issues with using Mouse detection events on UIObjects for a long time, so I was surprised to see this was happening again. However, using your repro, I added colour indicators to the frames which appears to be displaying as expected, but the indicator frame doesn’t turn visible.
Same problem here…
It seems Roblox script is not respecting the MouseEnter and MouseLeave correct order, when the mouse moves fast.
I put a print with a counter and the name of the instance inside both MouseEnter and MouseLeave.
That’s what I got when the mouse moves slowly between two instances:
1 -> Enter ImageButton1
2 -> **** Leave ImageButton1
3 -> Enter ImageButton2
4 -> **** Leave ImageButton2
But then, if I move faster from ImageButton1 to ImageButton2:
5 -> Enter ImageButton1
6 -> Enter ImageButton2
7 -> **** Leave ImageButton1
8 -> **** Leave ImageButton2
As you can see MouseEnter from ImageButton2 is being fired BEFORE MouseLeave ImageButton1 …
So, the question is: how to avoid Roblox to run in this Assyncronous way?
I think I solved the problem:
Just insert a wait() at the very beginning of MouseEnter event. 
This will avoid that asynchrony problem.
3 Likes
I would recommend waiting a frame using e.g. RenderStepped rather than wait(). With wait() you get typically a 2 frame wait, and it is not guaranteed to resume at the earliest possible moment due to potential throttling. Signals like RenderStepped/Heartbeat/Stepped are guaranteed to run every frame, and are never deferred to the next frame.
5 Likes
Putting a renderstepped wait fixed the problem, but we really shouldn’t have to do this.
9 Likes
I am still experiencing this issue to this day, but only with CoreGui, if an engineer is reading this, please fix the issue with CoreGui
Here’s a video of the problem:
robloxapp-20220303-1725267.wmv (83.5 KB)
No clue how this is still a prominent issue four years later in 2022. I’ve been using a custom implementation because of this for the last few years (when I shouldn’t even have to), and I decided to try it out again to see if it got fixed during that time, but it still fails to run in order.
It runs the next button’s Enter before it runs the current button’s Leave. MouseLeave actually fires out of order.
4 Likes
It mainly happens on mobile, does it happen on PC too?
I also have this problem when working with hovering UIs. My way around this is to use PlayerGui:GetGuiObjectsAtPosition(x, y), with the x and y arguments being the mouse position. It’s a hacky method, but it seems to work for me.
4 Likes
Hello! We are following up to see if this bug is still affecting devs as we are having some trouble reproducing this issue.
If this issue is still affecting you, please reply back with details and a test place if possible. Thank you!
Not entirely sure but it seems like it has been fixed? IIRC the last few times I’ve been using this event it has been working fine regardless of mouse speed
Hmmm 
just came across this post and can’t help but wonder, is this still planned? Does TweenService offer any extra benefit over using these alternative methods?