here gimp is still gtk2 though. but:

gedit here - so gtk3. preferences dialog...

gedit with lots of terminals behind it ...

same story with sound recorder and about dialog or keyboard shortcuts dialog... i see nothing bad happening...

waaait. is this just the last release tarball or have you tried git for updates/fixes?

then you're almost totally up to date. nothing that will affect focus or window stacking etc. ... i cannot see/reproduce anything you have there. i do suspect gtk3 has some issues - gtk3 windows do not change their appearance when they have foruse or not with CSD. this happens in e AND happens in good old fvwm. if gtk breaks in fvwm then it's gtk's fault. not to mention gtk insists on doing CSD even in fvwm so it looks visually broken anyway...

yup... tested. broken for sure in fvwm2, twm and in e - at least in displaying if the window looks focused or not. this would be a gtk3 bug. 100%. not your bug you have exactly but there is an indication that gtk3 is not doing things right.

Oh...
I'll try to search the information about this GTK3 problem. I leave this task open to put here any workaround if I find it.

As I could not find anything about this problem in Internet, I tried to test a little bit more myself.
So, I tried to reproduce the problem in different WMs I have installed on my PC:

• LXDE
• OpenBox
• Worm (something really basic)

And I could not reproduce the problem anywhere but in Enlightenment!
So, even if GTK3 applications do something wrong - all other WMs, even basic ones, arrive to manage it, I don't lose focus. So, the problem can be fixed at WM level.

you can send a patch when you find it... :) i can't do anything.. i don't see any issues... as i have shown... i cant go fix something when i dont know what it is. but gtk3 is broken in DRAWING the focus state of a CSD frame as i mentioned above. that's a gtk bug.

To find it and to send the patches I need to know where to search. The Enlightenment codebase is huge.
As far as I understand, the problem comes from bad focusing of the parent window:

• for leafpad - on dialog open (probably, more simple to search)
• for RazorSQL - on dialog close

In both cases I need to know where the Enlightenment code that manages visibility and focusing of windows is situated.
I use some GTK3 application on daily basis, I'm really penalized by this bug. I'm ready to search, but I need some help.
Even if I want to open a GTK3 bug - I'll need some debugs anyway.

e_comp_x.c - look for all the callbacks handling x events and then add printfs in each to see what is going on... like _e_comp_x_reparent() _e_comp_x_hide() _e_comp_x_show() and do on - the ones that have some Ecore_X_Event_xxxxx as the last parameter. especially things like _e_comp_x_focus_out(), _e_comp_x_focus_in() and _e_comp_x_client_property() also what happens to focus timers ... there is a lot there and this may require a lot of chasing to find out what is going on.

I checked the dependencies of programs that I used to reproduce this bug.
Surprise - leafpad is NOT GTK3 program, it is a GTK2 program.
It is really important, as GTK2 programs do not use CSD.
As about Java applications - from release notes of Java 11:
"JavaFX will now use GTK 3 by default on Linux platforms where the gtk3 library is present. Prior to JavaFX 11, the GTK 2 library was the default."
So, all Java applications on my system (FreeBSD with default java version 8) are surely using GTK2. And the bug is present for several GUI java applications I've tested.
Another application that does not work correctly - flphoto, image viewer, based on FLTK toolkit (not related to GTK either). The main application window is hidden when I open any modal dialog, it does not come back when the dialog is closed.
So, the problem is NOT GTK3 related, and even NOT GTK related. It can be reproduced with different applications, that use different GUI toolkits.

I can reproduce the problem starting Enlightenment in Xephyr session under another WM. I'll try to debug it there.

I see _e_comp_x_hook_client_focus_unset_job called, then _e_comp_x_hook_client_focus_set_job called
in case of pressing "About" in menu.
There is a difference between VLC (works fine) and Leafpad (works bad):
_e_comp_x_hook_client_focus_unset_job arrive with the name of main app in both cases
_e_comp_x_hook_client_focus_set_job arrive with the name of main app in case of VLC and with the name of another app (Terminology) in case of Leafpad.
So, after click on menu "About" Leafpad loses focus, then modal dialog opens, on close of this dialog the focus comes back to Terminology (normal).
I see where the name of window for _e_comp_x_hook_client_focus_set_job it set, but it does not help me. I still don't understand who and where does choose the window to set focus after _e_comp_x_hook_client_focus_unset_job

...BTW, Enlightenment working under Xephyr is simple to debug with QT Creator.

After some debugs, I see that the main window of Leafpad is skipped in e_desk_last_focused_focus at line 430 because ec->lock_focus_out is 1 for this window. So, the next window (Terminology) gets focus after selecting a menu line and closing menu.

The commit ea973717708a71b62e4661b4dad7b2bd15bc23ef solved the problem with GTK applications Leafpad and Gimp.
The problem with Java applications are still here (tested with JXplorer and RazorSQL).

...I think there were two different problems as the focus was lost at different moments - for Leafpad the focus was lost BEFORE secondary window opening, for JXplorer - AFTER the secondary window closing. The mentioned commit solved one of these problems, the second remains.

After some debugs of loosing focus in JXplorer, I see that the function e_desk_last_focused_focus is called twice after pressing "OK" in "About" window. During the first call, the main window correctly gets focus. During the second call the main window is skipped at line 430 because ec->lock_focus_out is 1 for this window.
First call:

Almost the same thing for Telegram Desktop. The function e_desk_last_focused_focus is called once here, but for the main Telegram window ec->lock_focus_out is 1 too, so the window is skipped, the focus goes to Terminology window.

It seems that the issue with Telegram was not present before raster's commit ea973717708a71b62e4661b4dad7b2bd15bc23ef.

YESSSS!!!
I cannot reproduce the issues anymore.
Thanks a lot, raster!