As a roblox player and developer, it is very annoying to have your mouse locked in first person because the developer didn’t know GuiButton.Modal exists and is false by default. This happens with essentially every game on the platform, and is pretty much always unintentional.
As it leads to UIs getting stuck on your screen (like prompts) and being unable to close them, unless you just so happen to be on a PC and can press O to zoom out. But your straight out of luck if the game is first person only, so your then forced to rejoin the game or pray the developer has ResetOnSpawn enabled on their ScreenGuis.
This property is only useful for fps games, and fps games are not the majority of games on Roblox so having it true by default it would help solve a lot of these issues in games.
This is especially demonstrated by this bug report:
In most cases, this will be not good. Even if I just add my custom topbar, with some buttons for stat panel, inventory panel and such - they don’t need to have modal set to true at all - cuz this will break first person view in a lot of cases.
Remember - if person not knows abt it’s existance, then there will be another “wave” of users, saying “how to lock mouse at center, I tried UserInputService and even it not worked!!!”
There’s so many games that mistakenly leave Modal on then it breaks first person and similar. The only issue is a developer and not the default value of the boolean. But it is better if it was disabled.
There are cases you may want it on, there are some you don’t. Fact is you only need one UI with Modal on.
The Modal property itself is completely innocent regarding The Chrome Unibar bug I posted.
I could have used the J button to open the settings in the game “Pressure” to free move my mouse and toggle the chat.
But not every game… has that built-in and nor should one be forced to do that, I guess?
But I tried it that way, and realized that it was a bug that it doesn’t work.
I see Roblox’s UI as some kind of “wrapper” which is supposed to… work for a Player at all times, and not let games obscure it, but also not put a burden on a game’s developer to adjust things based on Roblox’s UI… (the hotbar… is an exception I guess, maybe there’s some methods for it idk)
You don’t know how many games either have it mistakenly ON or OFF.
Even Twin Atlas themselves forget to set or unset Modal.
So, at that point it would make sense to have a function that can check whether “Modal Mode” is being enforced by any UI and or have some kind of debug visualization for that in Studio. I think this would be a more interesting approach and especially helpful for those that just quickly check if a game looks “alright” through Studio or something idk.
Majority of games don’t benefit from the default being false, so why should the default not reflect the majority of use cases?
Plus I’d imagine it’d probably be added as an optional Workspace flag (because backwards compat), so when that flag is enabled its default is true and vise versa.
Also I think your confusing the states of Modal? As the mouse wont be locked in first person (if true) allowing one to use an inventory GUI with their mouse whilst in first person.
Modal property already exists. Making it so creating new buttons will make modal autotrue will affect studio only. What this “flag” will control in live game?
Because this is not the way to solve the root problem you bring up in your original post. The root problem is that a lot of developers don’t have an understanding of the Modal property and its significance to begin with, and by suddenly changing the default of it to true this only further causes problems because those developers still don’t know about it and creates issues in cases where it should not be true.
Not even beginning to mention the fact that this would suddenly break numerous scripts across a lot of games that are dynamically creating GuiButton instances because buttons that they expected to default to Modal = false now suddenly default to something unexpected.