Fix BaseButton input when enable_long_press_as_right_click is true

[syntaxerror247]

This PR fixes a touch behavior issue that occurs when enable_long_press_as_right_click is enabled.
regression from #110893

The following describes the behavior before and after this change. A normal tap always generates a press event.

When Action Mode = Button Release and Button Mask = Mouse Left

• Before this PR: A long press triggers a button press action even though the button has not been released yet.
• After this PR: A long press does not trigger any action. When a long press is detected, the original touch is canceled and enable_long_press_as_right_click generates a Mouse Right event instead. Since the button is configured for Mouse Left, no action is triggered.

When Action Mode = Button Release and Button Mask = Mouse Right

• Before this PR: A long press triggers a button press action before the touch is released, and another press action is triggered when the touch is released.
• After this PR: A long press triggers a single button press action when the touch is released.

When Action Mode = Button Press, the behavior remains unchanged:

• Button Mask = Mouse Left: A press action is triggered immediately on touch.
• Button Mask = Mouse Right: A press action is triggered immediately on touch. If the touch is held long enough to become a long press, an additional press action is triggered for the right-click event.

[syntaxerror247]

cc @Alex2782 @Kazox61

[ace24713]

I'm curious about how some of this works...

When a long press is detected, the original touch is canceled

How does that work? I see InputEventScreenTouch has a "canceled" property, but I don't see anywhere in base_button where it's actually checked, so I find it hard to believe it handles everything intently and is left in a good state in all cases. Call it a hunch.

When Action Mode = Button Release and Button Mask = Mouse Right ... A long press triggers a single button press action when the touch is released.

That's also curious. If it ignores emulated events, how does it even respond to the emulated right click? Are emulated right-click events not set as DEVICE_ID_EMULATION? I mean I guess that'd be fine as long as it works, it's just unexpected.

A normal tap always generates a press event.

If "always" in this context means even when Button Mask = Mouse Right, that sounds like another regression too. Before multitouch support, a button with Mouse Right would not respond to short taps, but would respond to long presses. (worth noting I didn't explicitly verify that, but it's sensible)

Button Mask = Mouse Right: A press action is triggered immediately on touch. If the touch is held long enough to become a long press, an additional press action is triggered for the right-click event.

Similarly to the above, this is probably not how it would have behaved before multitouch support.

[syntaxerror247]

When a long press is detected, the original touch is canceled

How does that work? I see InputEventScreenTouch has a "canceled" property, but I don't see anywhere in base_button where it's actually checked, so I find it hard to believe it handles everything intently and is left in a good state in all cases. Call it a hunch.

Code checks for !event->is_pressed() which also handles canceled event. As you can see in the changes, where press action is triggered, I've now updated the check to event->is_released(), so it doesn't trigger a press for canceled events.

When Action Mode = Button Release and Button Mask = Mouse Right ... A long press triggers a single button press action when the touch is released.

That's also curious. If it ignores emulated events, how does it even respond to the emulated right click? Are emulated right-click events not set as DEVICE_ID_EMULATION? I mean I guess that'd be fine as long as it works, it's just unexpected.

Yes, right click generated by enable_long_press_as_right_click setting, does not have DEVICE_ID_EMULATION. These are like regular mouse click. DEVICE_ID_EMULATION is only being used for emulate_touch_from_mouse and emulate_mouse_from_touch setting.

A normal tap always generates a press event.

If "always" in this context means even when Button Mask = Mouse Right, that sounds like another regression too. Before multitouch support, a button with Mouse Right would not respond to short taps, but would respond to long presses. (worth noting I didn't explicitly verify that, but it's sensible)

Button Mask = Mouse Right: A press action is triggered immediately on touch. If the touch is held long enough to become a long press, an additional press action is triggered for the right-click event.

Similarly to the above, this is probably not how it would have behaved before multitouch support.

Yes, button mask is ignored for touch input. This does sounds like a regression but I'm not sure what we can do here, you know touch have no concept of button mask.

[ace24713]

Code checks for !event->is_pressed() which also handles canceled event. As you can see in the changes, where press action is triggered, I've now updated the check to event->is_released(), so it doesn't trigger a press for canceled events.

Ohh that makes sense, I was not aware that is_released is cancel aware. 👍

Yes, button mask is ignored for touch input. This does sounds like a regression but I'm not sure what we can do here, you know touch have no concept of button mask.

If I were to make a proposal...

In terms of regression minimization, I think treating touch inputs as left mouse events would be simple. That would be intuitive enough, I certainly wouldn't expect a touch input to be able to press a button coded to respond only to right mouse.

Alternatively...

What about adding "touch" as a potential mask option? That way buttons can be individually set to respond to whatever sorts of inputs the user wants. For example I could set a button to respond to mouse events only (which also works as a compatibility setting) or respond to touch and right mouse, touch and right and left mouse, or any combination.

[m4gr3d]

The code change looks good.

[syntaxerror247]

What about adding "touch" as a potential mask option? That way buttons can be individually set to respond to whatever sorts of inputs the user wants. For example I could set a button to respond to mouse events only (which also works as a compatibility setting) or respond to touch and right mouse, touch and right and left mouse, or any combination.

I personally like this option, but final call on this would be from Input or GUI team. It would be great if you can make a proposal with both of your suggestions.

[ace24713]

I personally like this option, but final call on this would be from Input or GUI team. It would be great if you can make a proposal with both of your suggestions.

Gotcha, proposal opened here:
godotengine/godot-proposals#15163

[Repiteo]

Thanks!

[Repiteo]

Cherry-picked for 4.7.2.