As the title says, there are a few issues which started occurring recently and cause a discrepancy with DragDetector behavior between mobile and all other platforms.
MouseHoverEnter and MouseHoverLeave firing incorrectly:
a) Expected behavior:
The mouse hover events need to fire regardless of permission policy (if enabled) on mobile like they do on desktop and gamepad in the following order:
I. MouseHoverEnter (on mouse enter, fired before PermissionPolicyCheck no matter what if it’s enabled),
II. PermissionPolicyCheck if enabled,
III. MouseHoverLeave (on mouse leave, fired no matter if PermissionPolicyCheck passes or not).
Video clip showing the **correct** behavior **with** PermissionPolicyCheck enabled:
Video clip showing the **correct** behavior **without** PermissionPolicyCheck enabled:
b) Current behavior:
The mouse hover events fire in the wrong order and incorrectly with and without permission policy enabled on mobile:
I. PermissionPolicyCheck if enabled (should not fire first but does),
II. Both MouseHoverEnter and MouseHoverLeave fire on mouse enter and after PermissionPolicyCheck if it’s enabled, MouseHoverLeave obviously should not fire at this moment,
III. Both MouseHoverEnter and MouseHoverLeave fire on mouse leave if it’s enabled, MouseHoverEnter obviously should not fire at this moment.
Video clip showing the **incorrect** behavior **with** PermissionPolicyCheck enabled:
Video clip showing the **incorrect** behavior **without** PermissionPolicyCheck enabled:
Where the issues occurs:
in the Studio Device Test tab at all Phone and Tablet Emulations,
iPad Pro, iPadOS 17.5.1 (21F90) Roblox App version 2.631.472,
iPhone 13 mini, iOS 17.5.1 (21F90) Roblox App version 2.631.472.
When the issue started occurring:
A few weeks ago, there was a short time period when everything worked correctly (mobile behavior didnt stand out).
Note: A test world file has been included for staff-only.
I have a fix coming. Touch devices are not naturally suited to the concept of hover, because you cannot track their location until you press down.
So we have special code for the touch case. This is why touch devices show behavior that is different than other devices.
On touch devices, we process touchStart and touchEnd events and send them to the hover code to kind of simulate a hover. The timing of hover callbacks was less important when we only had clickDetectors, But since DragDetectors have all kinds of events and callbacks that should be sandwiched between hoverEnter and hoverLeave, new problems have arisen, as you’ve seen.
I believe we have a fix, but it will take some time to get into released code.
In the particular case of the OP’s example, the hoverCode was only being used to determine state for the permissionPolicy, and not change visuals. So I’ve advised them to move their hoverEnter code into their permissionPolicy method, and their hoverLeave code into dragEnd. The net result is the same, and it will work today. If others are having a similar problem, they might try this approach.
I’m sorry to report that I must mark this bug as “won’t fix.”
I have gone over hoverEnter timing issue with our game engine team.
The problem is that they cannot force the hoverEvent to be immediately processed. It is part of a deferred queue and they cannot break that paradigm. So you cannot be guaranteed that hoverEnter will be called before your permissionPolicy callback in the case where you are using a touch device.
I have given you a workaround for this, which is to move any hoverEnter testing code into your permissionPolicy code, and then to move your hoverEnd code into dragEnd.
You should still be able to use hoverEnter/hoverLeave to change locate highlighting and such, you just cannot set state that is relied on during drag processing.
I’m sorry it took so long to reach this conclusion. Please know that we tried, but could not come up with a solution that honors the needs of our game engine’s event processing requirements.