PlayerMouse: X, Y, ViewSizeX and ViewSizeY set to 0 when chat bar is used

PlayerMouse.X, PlayerMouse.Y, PlayerMouse.ViewSizeX and PlayerMouse.ViewSizeY are all set to 0 after one of the following events:

[ol]
[li]The chat bar is used (i.e. when the slash key is pressed, when text is typed into the chat bar).[/li]
[li]One of the camera control hotkeys “io,.” is pressed.[/li]
[/ol]
The bug pertains until the mouse is moved or any mouse button is pressed. In other words, after the chat bar is used or camera hotkeys are pressed, PlayerMouse.X, PlayerMouse.Y, PlayerMouse.ViewSizeX and PlayerMouse.ViewSizeY will all stay 0 until one of the following events is fired:

[ul]
[li]PlayerMouse.Move[/li]
[li]PlayerMouse.Button1Down[/li]
[li]PlayerMouse.Button1Up[/li]
[li]PlayerMouse.Button2Down[/li]
[li]PlayerMouse.Button2Up[/li]
[/ul]

This bug occurs 100% of the time. It has been confirmed by both myself and a friend in both ROBLOX Studio and Online Play modes.

Is there a “normal” way to detect if the user is writing in the default chatbox in first place?
I currently rely on the behavior of this bug (check if the mouse’s position is (0,0)) to detect if someone writes in the chat, which then ignores keyboard events…

[quote] Is there a “normal” way to detect if the user is writing in the default chatbox in first place?
I currently rely on the behavior of this bug (check if the mouse’s position is (0,0)) to detect if someone writes in the chat, which then ignores keyboard events… [/quote]

It’s possible to put your mouse at 0,0. While it’s an extreme edge case, converting to use ViewSize to check for this bug should be painless and won’t result in edges cases. That’s what I do, anyway.

I’m still not convinced that this is actually a bug.

There should be a proper way to get the 3D viewport size on a device without using PlayerMouse.ViewSize, since PlayerMouse.ViewSize correctly displays something other than the viewport size while the 3D viewport is not the currently focused element for that mouse (Such as when you are typing in a textbox, or before the game window actually gains focus for the first time).

Yea that’s of course better, didn’t know those properties were also set to 0. It’s still not a proper way to check it though :P.

Have you tried using UserInputService? The InputObject will return the position with mouse movement no matter what.

Basic Example, which works online and shows up in the dev potato

game:GetService("UserInputService").InputChanged:connect(function(inputObject)
	if (inputObject.UserInputType == Enum.UserInputType.MouseMovement) then
		local pos = inputObject.Position;
		print("Mouse ",pos.X, pos.Y);
	end 
end);

This should work for the X and Y at least. ViewSize* is definitely a problem though.

I actually use this to determinate this to check whether a player is chatting. Please do not change this behaviour as long as we don’t have a Player.IsChatting property.

The problem has been found. A fix will probably be out in one of the next couple releases.

Does this break chat detection through checking these properties? If so, is there an alternative?
It’s quite important to be able to detect chatting in some way, I’d say…

“If so, is there an alternative?
It’s quite important to be able to detect chatting in some way, I’d say…”

Well, if you really want to detect it you can always grab the the Chat script from GitHub - Roblox/Core-Scripts: All of ROBLOX's core client scripts., insert it into your place, disable the normal chat, and add a hook that your other stuff listens to in the chat script.

Doesn’t that remove bubblechat, disable the ability to have the chat logged (for moderation) and potentially break part of the chat due to the lower access level though?

It’s not really an optimal solution anyway, in my opinion.

“It’s not really an optimal solution anyway, in my opinion.”

Unfortunately we haven’t really decided how to best tackle the problem of CoreGui components communicating back and forth with normal game components yet, so there’s not really a good way to expose something like that.

“potentially break part of the chat due to the lower access level though?”

You’d have to make it use a “Chatted” bindable instead of :Chat(), but that’s really it.