Create a VideoFrame, ImageLabel, ImageButton, or TextLabel by script. Observe its “BackgroundColor3” property is 163, 162, 165. You can also see the same weird funkiness if you insert a VideoFrame via the Asset Manager or Toolbox
In comparison, insert a VideoFrame, ImageLabel, ImageButton, or TextLabel from the Insert Basic Objects widget. Observe its “BackgroundColor3” property is 255, 255, 255.
No matter the workflow, all of these UI objects should have the same BackgroundColor3 value. Ideally this is 255, 255, 255 to have parity with images/decals.
Actual Behavior
Various UI elements have a seemingly random grey BackgroundColor3 value when inserted/created a specific way.
Workaround
Set the BackgroundColor3 to 255, 255, 255 manually.
Issue Area: Engine Issue Type: Other Impact: Low Frequency: Constantly Date First Experienced: 2023-03-15 00:03:00 (-07:00) Date Last Experienced: 2023-03-15 00:03:00 (-07:00)
This is something that I believe has no fix, as is now totally late to do so. Changing the default values of these instances when created via Instance.new isn’t ideal because many people rely on it.
This happens with any instance you create using the ways Roblox Studio provide like the “Insert Object” right there though. They seem to adjust certain properties to how they expect their users to use those instances the most when being manipulated in Studio.
See, a similar issue occurs with parts in terms of SurfaceType:
Left: Script
Right: Insert Object
Though I can agree that this can cause many confusions and unexpected results sometimes. Like inserting a frame into the UI via a script expecting it would be fully white, yet it’s gray. Inserting a part, but it has this ugly surface. Etc…
This is the expected behavior. It’s a combination of two things:
Instances created via a script must have the same initial properties to maintain backwards compatibility for existing experiences that expect them to start out a certain way.
As Roblox has evolved what the “right” defaults for various Instances are have changed significantly, so Studio will apply an updated set of defaults when you use insert object.
There’s not much value in solving either side of this dilemma: Changing the defaults for creation via script would break a lot of content out there, and even if there were an option to insert the same thing that a script creates via insert object, nobody would use it because the old defaults are not good.
Only thing I’ll mention is that this difference creates an unclear expectation for what the default property is for some instances.
Changing the default breaks backwards compatibility, making insert respect the actual defaults is undesired. Perhaps there may be some way to convey this difference in behavior besides trial and error (perhaps in the “Object Browser” widget?). I’m used to this for Parts, but not UI elements. The FTUX is likely confusing.
I think the real eventual answer is dependency management: Very few things actually want to be calling Instance.new, right now they just have to be because there’s no good way for them to bring prefab Instance hierarchies to clone from along with them into whatever context they’re inserted into.
If there were a good dependency management solution you could point at a prefab Instance hierarchy and somehow have it always come along with the script without it being a direct child.
