Setting Active to true doesn’t work for many ui in my game even when the zindex of the ui i set to active is higher than the ui under it, it still clicks buttons and things underneath that ui. it seems to happen with CanvasGroups and Frames for sure. I haven’t tested all elements but those are the main ones this is needed on. this happens on my Intel MacBook but doesn’t seem to happen on my iPhone
It seems to sink input from getting to the actual game world on both devices but not from getting to ui under ui which needs to be fixed. Like i can’t move my camera while swiping / dragging on an “Active” frame which is good but that’s about the most it stops. when it comes to ui underneath it interacts with it and can i click buttons and more that are invisible to me which shouldn’t happen
You guys need to test this more because i’m not exactly sure what works and what doesn’t on which devices. i just know it is definitely wrong in studio and player on my Intel MacBook
Expected behavior
When a gui is set to Active = true, nothing behind that ui should be able to be clicked, scrolled, swiped, tapped, etc on all devices that Roblox supports. Gui properties should do the same thing on all operating systems
So I took a look at this, we’ve discussed fixing this before, but it turns out a lot of experiences rely on this broken behavior. Unfortunately, that makes correctly addressing the issue rather difficult.
Since buttons sink clicks, I suggest using something like a fully transparent image or text button that fills the frame in order to stop clicks.
ive been noticing an increasing amount of quite high-prio bug reports being left as unfixed due to it potentially disrupting older games.
are there no considerations for fixing it in places that were either
A) created after the change was made
B) older places that manually opted-in to the fix?
it could of course still cause incongruousness with third-party packages/OSS tools that quietly relied on this behavior, however I’d argue it’s a necessary step of better behavior for everyone else.
I suppose the new behavior could be added as a flag under the StarterGui so it doesn’t affect old games?
Otherwise, the Active property as it currently stands is incredibly unintuitive.
EDIT: Even using an ImageLabel or TextButton still doesn’t sink input for the HoverImage behavior on buttons underneath.
We’re considering how to make this change, especially since any experience that relies on this broken behavior would already be broken on Mobile unless they use a completely different UI. In all likelihood a fix would probably be a three-phase rollout:
We ended up resolving this issue by introducing a new property: GuiObject.InputSink
Setting the property to Enum.InputSink.Activate should work the same on all devices. And setting it to Enum.InputSink.All allows you to sink hover/mouse enter/mouse leave events as well.
This update has been made with no warning (as far as I am aware) and the 3 phase rollout has not even been announced either as said in the previous reply.
For example, before the update, I had a fire button with Active set to false so that the player can move the camera while shooting, but now, they can’t !
Some other players are also reporting that many buttons don’t work when they touch it most of the time, so they have to try many times before it actually detects the touch. In the video below, you can see the issue clearly at 00:13.
Do I have now to urgently find a quick fix for all my impacted GUIs or is it still possible to roll back with proper rollout ?
The change will be rolled back, the change was not supposed to require a 3-phase rollout and was meant to be fully backwards compatible. We had tested a wider variety of scenarios, but obviously missed something.
Thanks for rolling this back, was there any specific reason this change wasn’t included in the patch notes? We spent a good hour to two trying to understand why we suddenly our buttons on mobile doesn’t work, with no public notice of this at all expect this report
As said above, the idea was that this change would not alter any existing behavior. Ideally we wanted this feature to be enabled without crashes, then make a broader announcement. The behavioral changes were unexpected.
The flag should finish rolling back around 10:00 AM PST.
Whilst that makes sense in a perfect world, we don’t live in one. Even backward compatible changes should be in the patch notes. We’re all human and make mistakes, so there will always be bugs like this, and it’s a lot faster to find out why if everything is transparently documented.
I think this is the third breaking change / bug that’s silently gone out without patch notes and affected our experiences just this year.
(You might just be following policy set from above, so this is more a feedback for whoever set that policy if you could send it up the chain please. I have fed back similar on CFP and Top Engaging Experiences but it still keeps happening).
That is my fault and I’m sorry for missing this. I’ll escalate with DevRel to see if we can make changes internally, so people don’t miss adding the patch notes, especially considering that impacts your development schedule.
