I also have this issue in 4.3-dev3 -- I was about to report it myself

My specs:

Version that's bugged: (ctrl-shift-f isn't usable without a mouse click to refocus the popup)

Godot v4.3.dev3 - Manjaro Linux #1 SMP PREEMPT Tue Nov 28 19:17:55 UTC 2023 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 750 Ti (nvidia; 545.29.06) - AMD FX(tm)-8350 Eight-Core Processor (8 Threads)

Version without the bug:

Godot v4.1.3.stable unknown - Manjaro Linux #1 SMP PREEMPT Tue Nov 28 19:17:55 UTC 2023 - X11 - Vulkan (Compatibility) - NVIDIA GeForce GTX 750 Ti (nvidia; 545.29.06) - AMD FX(tm)-8350 Eight-Core Processor (8 Threads)

Bisected to 40d69c2 #86441
CC @Mequam @dsnopek

Tried to investigate "editor/find_in_files.cpp" ("FindInFilesDialog::_notification") and found that if replace
callable_mp((Control *)_search_text_line_edit, &Control::grab_focus).call_deferred();
with
_search_text_line_edit->grab_focus();
the problem is gone.

Tested and this doesn't seem to work in current master.

CC @bruvzg @KoBeWi - maybe we can improve the Find in Files focus handling logic to make it less dependent on the timing of events.

Well call deferred is usually a way to fix such issues, because you make something happen last (in most cases). It would be nice to know what causes the focus steal. I can't reproduce it on Windows (tried single window mode, as it can't even happen with multiple windows).

(tried single window mode, as it can't even happen with multiple windows).

For me on Linux (Fedora 40, KDE Plasma on Wayland, X11 DisplayDriver) the issue is only reproducible with multiple windows actually, and not reproducible in single window mode.

Huh I tested with multiple windows and seems like you can focus the editor, it just doesn't accept input.
Still can't reproduce the bug though.

This has been a little tricky for me to reproduce. It's not reproducible on my system (Ubuntu 22.04) with i3 (my usual environment) or GNOME. I used multiple window mode in both cases, and tried both Forward+ and Compatibility (above, someone said it happened for them only on Forward+ and not Compatibility).

However, I just setup a Fedora 40 VM in VirtualBox, and I am able to reproduce the issue there! (using Compatibility, since getting Vulkan running in VirtualBox is a pain)

Strangely, that is also GNOME, however, it looks like it's running on Wayland and so using xwayland. I wonder if that's the difference? On my host machine, I'm using real X11 in order to take advantage of the proprietary nvidia drivers.

It'd be great if other folks who are experiencing this issue could share:

1. The name of their window manager or desktop environment?
2. Whether or not you're using real X11 or xwayland?

In any case, I'll experiment with some changes to the code that was committed in PR #86441 to see if I can find a workaround.

I reproduce the issue on Fedora 40 KDE Plasma/KWin on Wayland myself, so using XWayland. I can test tomorrow if it's indeed not reproducible on the same system with KDE X11.

I just posted draft PR #93682 which fixes the issue in my testing.

I don't know if it reintroduces the bugs that PR #86441 aimed to fix, though, and I'm going to attempt to determine that.

In any case, I'd appreciate it if other folks who are experiencing the bug described here could test if my PR fixes it for you as well!