So, this is a weird bug.
Basically, if you have a ScreenGui inside of a ScreenGui and have any interactive element in it (e.g. a TextBox or a TextButton) - the interactivity of the element is disabled.
This means that Click events, Focusing and similar is disabled.
Why would you ever even go so far as to do such a thing?
I’m surprised that the sub-screen-gui items show up at all.
[quote] Why would you ever even go so far as to do such a thing?
I’m surprised that the sub-screen-gui items show up at all. [/quote]
Like I said in the OP, I was testing and moved a ScreenGui into another ScreenGui. Without noticing (because the Guis still rendered) I tested the place, and found out that my interactive features weren’t working, with no output messages. I found out by looking at the hierarchy when going to open the scripts that I had done that, and did some tests to make sure it actually was a bug.
Not a bug, that’s intended behavior. Otherwise the UI element processing would get exponential time complexity.
Oh, okay.
It was just some unexpected behaviour which I had come across. If it does that, then wouldn’t it be a better idea to prevent it from rendering at all?
[quote] Why would you ever even go so far as to do such a thing?
I’m surprised that the sub-screen-gui items show up at all. [/quote]
Surface gui inside a frame with clipsdecendants?
It’d be nice if we disable this kind of behavior, it may break some places though. Maybe I’ll take a look at it.