Since yesterday (03/07) I have started getting bug reports about the SurfaceGui shops with ScrollingFrames in one of my places no longer working. I looked into the issue and found out that scrolling is now very choppy and only works in one direction, and the buttons parented to the ScrollingFrame can no longer be pressed.
This doesn’t happen only my place and seems to be related to the ScrollingFrames parented to SurfaceGuis in general. It also happens both with the emulator and playing with an actual device so that shouldn’t be the problem. This repro file produces the same issue: ScrollRepro.rbxmx (143.4 KB)
Sounds like a lot of UI issues have been happening since yesterday. I pinged Tiffblocks who said she was working on an overhaul of the code in another thread, I’ll cross post her response here when I get one.
Scrolling seems to be fixed now, but the TextButtons are still not press-able on mobile devices. This can be reproduced by testing with the mobile emulator or on a mobile device with the ScrollRepro file in the main post, where you can see that the buttons are clickable with mouse input but not with touch input.
Have you tried listening to the Activated event on the button? This is the new preferred way of listening for mouse click/ Touch tap/ gamepad selection
Not 100% sure if i’m using it right but i tried this and i didn’t want to print at all, neither with mouse or touch. If i use MouseButton1Click it works with mouse but not with touch.
I’m pretty sure the buttons aren’t responding at all on mobile since the buttons have AutoButtonColor set to true and don’t show any type of reaction from mobile taps but works just fine with mouse clicks.
EDIT: Had forgotten to set the TextButton property to Active which made the Activated event work both with mouse and touch, but there is still the problem with AutoButtonColor and the MouseButton1Click event not working with mobile taps, which used to work before.
Cool. I’ll look into the mousebutton1click event, but fair warning: we plan on deprecating this function in favor of Activated. This doesn’t mean click will stop working, but it does mean that we want to encourage people to use the Activated event instead, and support for click working with other input types will not be supported at some point in the future.