ScrollingFrame scroll taking priority over (Image/Text)Buttons on Mobile

[KateyLuvzWaffls (Katey)]

The issue is that the ScrollingFrames sometimes have a higher priority over Buttons, and from the bug report for our game it appears to happen in specific circumstances.

---

The issue is not game specific.
ScrollPriority.rbxl (64.2 KB)

Visual aid for the issue (from the game);

[System information unrelated, as it appears to happen on all mobile devices and Device Emulation on Studio]

Expected behavior

What should happen;

• Player clicks on the TextButton on both ScrollFrames and the event fires in both.

A private message is associated with this bug report

[bluebxrrybot (blueberry)]

Is the ScrollingFrame Active? Mobile acts differently compared to PC regarding this property. For example, on PC, GuiButtons and TextBoxes are clickable when inactive, unlike on mobile.

Nice FNF Song Selection UI, by the way.

[KateyLuvzWaffls (Katey)]

The Active property had nothing to do with the issue, as shown in the .rbxl which pretty much shows what the issue is.

The workaround for it we are currently using right now, however, does involve setting ScrollingEnabled to false.

The workaround we are using to fix the issue

Frame.ScrollingEnabled=false; 
Frame:GetPropertyChangedSignal("GuiState"):Connect(function()
  Frame.ScrollingEnabled = (Frame.GuiState == Enum.GuiState.Press);
end);

[yoshicoolTV (coolyoshi)]

I find it a bit weird too but I guess there is some possible understanding to this

I guess on mobile Roblox thinks that the player wants to swipe instead of press so they prioritise swipe. The Solution I found in your repro is changing the ZIndex (2) of the frame cause I think it no longer thinks that the player is swiping

But yea totally weird behaviour

[thirdtakeonit]

Thanks for the report! We’ll follow up when we have an update for you.

[nomnomhungy (chad)]

Hi, KateyLuvzWaffls. Thank you for the report! It is expected behavior for GuiObjects at higher Z-Indices to sink input, preventing GuiObjects at lower Z-Indices from receiving that input event. In this case, the ScrollingFrame being “on top of” the button blocks the button from receiving the input as expected. As coolyoshi mentioned, the way to address this would be by giving your buttons a higher Z-Index than the ScrollingFrame. It is generally best practice to set the Z-Index deliberately instead of relying on its default value for this reason.

I understand this may be confusing, as this behavior is inconsistent with the behavior on mouse-and-keyboard. We are looking to make improvements to our input system in the future. Please rely on setting the Z-Index to resolve input ordering issues like this in the meantime.

Hope this helps!