Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buttons process "button_up" events differently with key input versus mouse input, after losing focus #81371

Closed
Novark opened this issue Sep 6, 2023 · 2 comments

Comments

@Novark
Copy link

Novark commented Sep 6, 2023

Godot version

v4.2.dev3.official

System information

Windows 11 [Vulkan (Forward+)]

Issue description

Edit: After thinking about this further, the behaviour with key-input might not actually be a bug, however, it remains inconsistent with how mouse-input is handled.

When a button loses focus (i.e. when pressing <Tab> to cycle to the next neighbour), a button will still process a button_up event for mouse-input, even though the button no longer has focus, however, it will not process a button_up event under the same circumstances for key-input. Note, however, that if the destination neighbour is also a button, then this destination button WILL process a button_up event via key-input.

In other words, if you press-and-hold <Left-Mouse-Button> such that the button node emits a button_down event, and then press <Tab> to make the button lose focus, and then you release <Left-Mouse-Button>, the button will still emit the button_up event.

In contrast, if the button has focus, and if you press-and-hold the <Enter> key such that the button emits a button_down event, and then press <Tab> to make the button lose focus, and then you release the <Enter> key, the button will NOT emit the button_up event (however, as stated above, if the destination neighbour is a button, then THAT button will emit its own button_up event)

This may be related to #81186.

Steps to reproduce

  1. Create a Container (I used HBoxContainer)
  2. Add 2 Buttons as children of this container
  3. Connect the button_down and button_up signals to functions that simply print something when these signals fire. If adding this code to both buttons, then make sure that each button prints something different to denote which button is emitting the button_down and button_up events
  4. Run the project
  5. Observe the difference between button_up events for mouse-input vs. key-input as described in the issue description above

Important: When doing a complete button press (button_down + button_up) using the <Enter> key, you can switch which node has focus half-way through the press. So you can register a button_down event on Button 1, and then press <Tab> to cycle to Button 2, and then release the <Enter> key to register a button_up event on Button 2. This seems to make intuitive sense to me, but it can still have unintended side-effects since you can't achieve the same thing with mouse-input.

Minimal reproduction project

Simple setup; no reproduction project necessary. Nevertheless, here's some copy+paste button code.

# Place me in the Button node
extends Button


func _ready() -> void:
	button_down.connect(button_down_handler)
	button_up.connect(button_up_handler)

func button_down_handler() -> void:
	print("Button #1 is pressed") # Change this to indicate Button #2 for the other button

func button_up_handler() -> void:
	print("Button #1 is released") # Change this to indicate Button #2 for the other button
@Sauermann
Copy link
Contributor

related to #52578

@Novark
Copy link
Author

Novark commented Sep 7, 2023

related to #52578

Thanks for linking this issue. Closing my issue, as it seems to be a duplicate. I don't think I covered anything here that wasn't already included in #52578.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants