You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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
Run the project
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 nodeextendsButtonfunc_ready() ->void:
button_down.connect(button_down_handler)
button_up.connect(button_up_handler)
funcbutton_down_handler() ->void:
print("Button #1 is pressed") # Change this to indicate Button #2 for the other buttonfuncbutton_up_handler() ->void:
print("Button #1 is released") # Change this to indicate Button #2 for the other button
The text was updated successfully, but these errors were encountered:
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.
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 abutton_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 abutton_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 thebutton_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 thebutton_up
event (however, as stated above, if the destination neighbour is a button, then THAT button will emit its ownbutton_up
event)This may be related to #81186.
Steps to reproduce
button_down
andbutton_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 thebutton_down
andbutton_up
eventsbutton_up
events for mouse-input vs. key-input as described in the issue description aboveImportant: 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 abutton_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.
The text was updated successfully, but these errors were encountered: