"Active" property does not sink input on some devices

Bug Reports Engine Bugs
,
#1

Screen Shot 2025-01-15 at 6.50.41 PM
Screen Shot 2025-01-15 at 6.50.41 PM728×140 33.6 KB

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

1 Like
#2

I also have this issue.

Using a Frame to block the player from clicking buttons 10 ZIndex under the blocking Frame.

Still processing input, despite the blocking Frame using Active and has a higher ZIndex than the button.

How is this supposed to work?

2 Likes
#3

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.

#4

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.

1 Like