Input Action System: MouseButton Bindings trigger over Active UI, while Keyboard Bindings do not (Inconsistency)

Bug Reports Engine Bugs
,
1

I am using the new Input Action System (InputContext, InputAction, InputBinding) to handle gameplay controls. I have noticed an inconsistency regarding how input is sunk/processed when interacting with UI elements.

When an InputAction is bound to a Keyboard Key (e.g., Enum.KeyCode.A), focusing on a TextBox or interacting with UI correctly suppresses the action. The Pressed and Released event does not fire, which is the expected behavior.

However, when the same InputAction is bound to a Mouse Button (e.g., Enum.KeyCode.MouseLeftButton), clicking on an active UI element (like a TextButton or an active Frame) does not suppress the action. The Pressed and Released event fires, causing gameplay actions (like shooting or hitting) to occur simultaneously with UI clicks.

This defeats the purpose of the abstraction provided by the Input Action System, as developers still have to manually check if the mouse is over a UI element, whereas keyboard inputs are handled automatically.

Affected Inputs:

  • Enum.KeyCode.MouseLeftButton (Left)

  • Enum.KeyCode.MouseRightButton (Right)

  • Enum.KeyCode.MouseMiddleButton (Middle)

Expected behavior

I expect InputBindings using Mouse Buttons to respect UI interaction just like Keyboard bindings do. If the cursor is over an UI element
the InputAction should not trigger its Pressed and Released event

7 Likes
2

Using InputActions for mouse buttons is borderline unusable because of this. We definitely need the option to check gameProcessedEvent like InputBegan has.

2 Likes
3

This is still happening as of today

1 Like
4

https://create.roblox.com/docs/release-notes/release-notes-703

image
image1431×108 7.33 KB

its good to see that this issue will be fixed with the release note 703 :partying_face:

5

If anybody needs a workaround to this, it’s pretty simple but depending on your framework and the state of your script environment, it might not be reliable, just hook this up to your inputcontext handler

local GPE = false
UserInputService.InputBegan:Connect(function(input: InputObject, gameProcessedEvent: boolean) 
	GPE = gameProcessedEvent
end)
InputAction.Pressed:Connect(function()
    if GPE == false then
      -- do code here...
    end
end
6

Seems to have been silently removed from the roadmap?

7

Hello, this issue will be fixed on 2/24. There are some games relying on the current sinking behavior because PlayerScripts currently sinks some gamepad inputs, so we’re giving them time to list their placeIDs to be blacklisted from this change. Full details here.

2 Likes