GUI AbsolutePosition doesn't respect IgnoreGuiInset

Bug Reports Engine Bugs
#1

Issue Type: Other
Impact: Low
Frequency: Constantly
Date First Experienced: 2021-04-11 00:04:00 (-05:00)
Date Last Experienced: 2021-04-14 15:04:00 (-05:00)

Reproduction Steps:
To reproduce:

  1. Place a ScreenGui in StarterGui
  2. Check the IgnoreGuiInset box
  3. Place a Frame inside the ScreenGui at the position (0, 0)
  4. Place a LocalScript inside the Frame and add the line:

print(script.Parent.AbsolutePosition)

Expected Behavior:
The script should print (0, 0) in the console (because the Frame is truly being rendered at the location 0, 0 on the screen).
image

Actual Behavior:
The script prints (0, -36) instead.

Workaround:
No workaround other than always adding (0, 36) to the AbsolutePosition.

10 Likes
#2

I don’t think it’s technically a bug. Even if it was, they couldn’t fix it because any code that relies on AbsolutePosition being relative to the topbar would be broken. Some of my own UI code would be broken by this, which would be sad.

Whenever I use AbsolutePosition, what I do is add Vector2.new(0, 36) to it, which is easy enough.

4 Likes
#3

IgnoreGuiInset was added retroactively, after the inset itself was introduced. To maintain backwards compatibility for games that had hard-coded the 0, -36 value we needed to make sure this property did not alter screen space coordinates. We could look at changing this, but I suspect many developers still rely on a hard-coded value therefore we probably won’t.

8 Likes
#4

Then this should have been documented if it’s not going to change. I can imagine lot of developers frustrated and confused over this miss information, I’ll make a DevHub request for it.

3 Likes
#5

Agreed. Actually, the DevHub page on AbsolutePosition is incorrect regardless of whether IgnoreGuiInset is checked. A frame at (0.5, 0.5) never has an AbsolutePosition in the center of the physical screen as the DevHub implies.

1 Like
#6

I’m struggling to find this exact example. Is it on a different page?

2 Likes
#7

Yes, that’s the page.
In the second paragraph there is an example with a 1920x1080 screen. It says that the AbsolutePosition of a frame at the position {0.5, 0}, {0.5, 0} will be (960, 540), which is never actually the case because of this -36 pixel offset. Please try this yourself.

#8

Also, the code example on that page doesn’t work with IgnoreGuiInset enabled.
That’s probably worth stating on that page.

#9

Thanks a lot, dude! I really was very confused

#11

I can confirm this is still an issue. The documentation doesn’t provide the fact that the AbsolutePosition property does not respect IgnoreGuiInset. The paragraph here does provide correct information in a scenario where IgnoreGuiInset would be respected:

For example, on a 1920 by 1080 screen, a Frame with position {0.5, 0}, {0.5, 0} would have an AbsolutePosition of (960, 540). If you were to place another Frame with position {0, 50}, {0, 50} inside that one, its AbsolutePosition would be (1010, 590). This example assumes each Frame has the default GuiObject.AnchorPoint of (0, 0), the top left corner.

But this is currently not the case. Here is a LocalScript I placed inside StarterPlayerScripts to prove this issue:

local Players = game:GetService("Players")
local GuiService = game:GetService("GuiService")

local playerGui = Players.LocalPlayer.PlayerGui

local screenGui = Instance.new("ScreenGui")
screenGui.IgnoreGuiInset = true

local Frame1 = Instance.new("Frame")
Frame1.Size = UDim2.fromOffset(100, 100)
Frame1.Position = UDim2.fromOffset(0, 0)
Frame1.Parent = screenGui

local Frame2 = Frame1:Clone()
Frame2.Position = UDim2.fromScale(0.5, 0.5)
Frame2.Parent = screenGui

screenGui.Parent = playerGui

print("Screen size:", screenGui.AbsoluteSize)					-- Screen size: 1920, 1078
print("Gui Inset:", GuiService:GetGuiInset())					-- Gui Inset: 0, 36 0, 0
print()
print("Frame1 expected Position:", Vector2.zero)				-- Frame1 expected Position: 0, 0
print("Frame1.AbsolutePosition:", Frame1.AbsolutePosition)		-- Frame1.AbsolutePosition: 0, -36 
print("Frame1 position difference:", Frame1.AbsolutePosition)	-- Frame1 Position difference: 0, -36
print()
print("Frame2 expected Position:", screenGui.AbsoluteSize / 2)	-- Frame2 expected Position: 960, 539
print("Frame2.AbsolutePosition:", Frame2.AbsolutePosition)		-- Frame2.AbsolutePosition: 960, 503
print("Frame2 Position difference:",
	Frame2.AbsolutePosition - screenGui.AbsoluteSize / 2)		-- Frame2 Position difference: 0, -36

Here is also a place file:
AbsolutePosition IgnoreGuiInset.rbxl (41.7 KB)

Frame1 (which is at the exact top left of the screen), for example, should have the AbsolutePosition of 0, 0, but this isn’t the case - its AbsolutePosition reads 0, -36. It’s offset by the Gui Inset of 36 pixels.

The fact AbsolutePosition doesn’t respect IgnoreGuiInset isn’t that impactful of an issue for me, as I was able to work around it. But could the documentation get updated to reflect the fact that IgnoreGuiInset isn’t followed?

#12

so what if backwards compatibility,
you guys added remote events and broke many old roblox games and which made them unplayable.

I mean yeah that made many people upset, and had to recode their game to make it even work.

but for this instance, it’s basically one line of code that you’ll have to remove. I mean you’ll have to remove this line for every script, but at least you don’t have to refactor your entire game to be functional.

I think fixing this bug will overall help in the long run.
plus if you give developers a reasonable amount of time to make this change. It could be beneficial.

by just simply adding this the documentation, not everyone would be able to immediately deduct that you need to add 36 pixel offset. or know where to look.

2 Likes