Tab navigation in a Vector3 inspector property doesn't properly give focus to spinboxes (DisplayServer regression)

[Zylann]

Godot 4 b3310a0
Windows 10 64 bits

Using the tab key to focus X, Y and Z parts of a Vector3 property in the inspector doesn't seem to work properly. In 3.2.1 it focuses each field one after the other by allowing to type numbers immediately. In master, it visually gives focus, but typing numbers doesn't work.

1. Create a Spatial
2. Go to its transform property and click on the X spinbox. Observe you can input numbers normally.
3. Hit the Tab key. Observe the Y field now looks focused, but typing numbers does nothing.
4. Hit Tab again. Observe Z is now focused and this time typing numbers works again. Sometimes it still doesn't work, not sure why.

[KoBeWi]

The field is properly edited when you press Enter after tabbing. Should be easy to fix, but maybe current behavior is already ok?

[Zylann]

Having to press Enter sometimes after pressing Tab to edit the next field is not ok.

[qez008]

Godot 4 alpha 12
macOS Mojave

I'm experiencing a very similar issue on mac. Tab navigation is practically unusable in alpha 12, while it works perfectly fine in the stable version. Pressing tab in the inspector can yield three different outcomes with a seemingly random occurrence:

All obtained by pressing tab or shift-tab. Only the middle actually allows you to edit the selected field with keystrokes. The issue seems to be not limited to just Vector3s.

[RedMser]

I think this is caused by #58490, but I did not try running a build before/after the commit.

There seems to be two independent issues, either of which can happen, when switching focus via tab:

1. The old popup closes, but the newly opened popup gets closed as well. That's the first screenshot of qez's comment.
2. The old popup stays open, but is not focused anymore, causing inputs to be redirected to the main window (not 100% sure on this one). That's corresponds to the last screenshot.

My assumption is that there are some notifications or signals which get emitted as soon as we tell the OS to show/hide the window, but there's race conditions. Those then either cause the messages to get out of order, producing invalid state. Or they arrive too early/late, causing certain actions to not succeed (such as which element gets focus next, or hiding the old popup before showing the new one).

I've tried debugging this a fair bit, but I'm not sure how to proceed.

[Stealcase]

Since the issue I opened was closed for being a duplicate, I'm just sharing a visualization of the bug and some insights I've had.

It seems that the field you are tabbing from has an impact on how the next field is selected.

• Notice how tabbing from a "boolean" field to a "Float_Range" field makes the field receptive to inputs, but tabbing from a "float_range" to a "float_range" does not? The next field is not selected properly. ("Volume DB" => "Unit Size" does NOT select field, but "Stream Paused" => "Max Distance" Does!)

The field is "Focused", but cannot accept input until you press "spacebar" or "enter", because there is no caret/cursor.
I think this corresponds to @RedMser's suggestion nr 1.

• Notice how tabbing from a "float_range" field to a pure float/int field (or any other field really) causes the double-selection bug. ("Max Distance" => "Max Poliphony", and "Panning Strength" => "Max Poliphony").

This corresponds to @RedMser's suggestion 2.

Further example of bug

Nobody else that I can see has reported this bug occuring in the Scene tree, but it exists there as well.
Trying to rename 1 or several files in the scene hierarchy triggers a popup/selection issue.

Expected behaviour

Mouse clicking on Node Y while in Rename State on Node X should instantly exit Rename State on Node X, and select Node Y. This worked in Godot 3.5, shown below.

Actual Behaviour

1. Pressing tab while in Rename State does nothing.
2. Clicking on another node while in rename state only exits the rename state: The original node retains focus.
3. 2 Clicks are required to select a new node.