GUI Inset behaving inconsistently

[Soliform]

When I add a screen gui, and disable IgnoreGuiInset, and set ScreenInsets to CoreUISafeInsets, then add a semi-transparent frame with position 0,0,0,0 and size 1,0,1,0, this is what I get:

You can see that the inset is a little bit further from the actual topbar’s visible space. This is not a huge issue, but whenever I get the position of the mouse cursor (which also considers GUI inset), the position for a Y height of 0 does not match the cutoff in the above screenshot.

This below is the position of the cursor when the Y is 0. (Y being LocalPlayer:GetMouse().Y)

When I place my cursor where the GUI frame is starting, the Y position of the cursor is 36 (which is also the height of the old topbar if I recall correctly). This makes me think that this behavior is unintentional and is a bug of double-adding the old and new topbar offset to the GUI inset.

If this is intention, it is very unintuitive and is also different from previous behavior (in my game which involves aiming weapons, we use a custom cursor positioned at the mouse’s X and Y and for some reason it is broken here when it worked fine before).

In an older version of our code, this issue does not exist even though we use the new topbar as well (you can see that the semi transparent frame covers the correct part of the screen). The properties of the ScreenGUI and frame are identical across both tests.

Across both places, running the command print(game:GetService("GuiService").TopbarInset.Height) outputs 58.

Expected behavior

I expect that the topbar inset behaves identically across both places, using the correct inset that accurately reflects the real size of the top bar as well as the Mouse’s X and Y positions.

A private message is associated with this bug report

[DrRanchDressing]

Hey @Soliform could you send us a place file that reproduces the issue?

[DrRanchDressing]

Hey @Soliform quick update - this item is still in our backlog to address. I don’t have an update on ETA at this time, however this seems like a bug with offset that we will consider resolving. Thanks!

[Soliform]

Hi @DrRanchDressing , I’m not able to reproduce the issue in a single place file, it seems unique to our development setup (which is the same across both test games, but seems to produce inconsistent results)

We have all our code under a MainModule that inserts various scripts into services when the game runs (e.g. everything under the module’s “ReplicatedStorage” folder is pasted into ReplicatedStorage service when the game runs)

Within that ReplicatedStorage folder, there is a UI folder with a “StarterGuis” folder. All the ScreenGUIs in that folder are pasted into StarterGUI, and only after that, are client scripts initialized.

I believe it has something to do with the way some new script / change we have introduced is somehow indirectly causing issues with coregui. (the first/second screenshot is from a new development build, while the third screenshot is from an older development module that has not been updated much at all). The only change I know for certain that directly interacts with the CoreGUI, is that we disabled the Health CoreGUI in the new development build (first/second screenshot).

I really doubt that it is specific to the place, because when we run the MainModule in other universes and places, it replicates the exact behavior (of either the first/second screenshot or the third, depending on which one is inserted). For this reason I’ve just had a hard-coded offset of 36 pixels from the mouse position calculation, which has worked reliably across many different places and universes to account for the strange gap.

All screenshots are from the same universe ID (2149670802), but the first/second one is from place ID 17025175921 and the third one is from 2149670802.

I’m not sure how helpful this information is, but apologies for the (extremely late) reply, I remember attempting to reproduce the issue in a baseplate, getting stuck, and then forgetting to follow up.