focus issues with Wine and Java apps

[fenugrec]

I'm having frequent focus issues with software running under Wine, as well as some java-based GUI apps (ghidra) . It goes something like this :

• trigger an action that opens a dialog
• interact + press Enter or otherwise exit the dialog
• focus is "lost" somewhere : not in another application, not in the parent window. Unclear who has focus at this point.
• it takes anywhere from 1 up to 8-9 consecutive mouse clicks inside the parent window before it gains focus again. I don't see a correlation between time or number of clicks.

With a different WM, and the same software, the focus behaves normally. I have experimented with different settings in icewm but nothing made a difference.

To reproduce : sometimes running 'winecfg', and opening + closing its "Add Application..." dialog, is sufficient to trigger the bug, so it has nothing to do with a particular piece of software.

I'm not even sure how to begin troubleshooting this. Suggestions welcome.

[gijsbers]

Could you give the output of icesh focusmodel for those applications.
Did you experiment with the winoptions?
It would be helpful if I could reproduce it with some concrete smaller applications.

[fenugrec]

Thanks for the reply.

Could you give the output of icesh focusmodel for those applications.

0x6400005 focusmodel Globally

It seems other regular programs have Locally ; if I click inside the terminal where I launched the icesh focusmodel command I get Passive. Interesting.

Did you experiment with the winoptions?

Not familiar with that, will look into it

It would be helpful if I could reproduce it with some concrete smaller applications.

Absolutely. So far the simplest is with just Wine itself and running its own winecfg as I mentioned; but even that is not 100% repeatable

[gijsbers]

Use icesh clients and set the winoption .ignoreNoFocusHint: 1.

[fenugrec]

Thanks for the hint, it would have taken me a while to figure all that out. For future ref (for me or others)

#find class name
icesh clients | grep ltspice
echo ltspice.exe.ltspice.exe.ignoreNoFocusHint: 1 >> ~/.config/icewm/winoptions
#reload winoptions
icesh winoptions

Using it for a few minutes, everything seems to behave normally. Amazing, this has been driving me up a wall for months. So,

• why do these 'foreign' programs have focusmodel Globally and what are the implications ?
• Is setting ignoreNoFocusHint a workaround for something weird about these programs, or does it address an underlying icewm / config problem ?

[gijsbers]

why do these 'foreign' programs have focusmodel Globally and what are the implications ?

You really should ask the developers of those programs, because that is also unclear to me. It doesn't seem to give them any advantage and they don't seem to do a good job of it.

Is setting ignoreNoFocusHint a workaround for something weird about these programs, or does it address an underlying icewm / config problem ?

I have investigated this several times before and sofar my conclusion is that IceWM adheres strictly to the protocol definitions from the ICCCM specification and those applications do not.

[fenugrec]

You really should ask the developers of those programs, because that is also unclear to me

Ah, so it's something they actively set/request, I thought it was assigned by icewm based on some rules/config.

IceWM adheres strictly to the protocol definitions from the ICCCM specification and those applications do not.

Fair enough. Thanks a lot for your time looking into this !

[zgrim]

@fenugrec i've had the same focus issues in icewm with java apps, e.g. IntelliJ IDEs, my workaround is running them inside Xnest (or Xephyr, but that one is abandoned, i think) + fluxbox (or openbox, etc, even twm), inside icewm

$ cat ~/bin/my-java-app
#! /bin/bash
set -euo pipefail

Xnest -full -depth 24 -sss -bw 0 -geometry 2560x1440 :2 &
# Xephyr -no-host-grab -screen 2560x1440 :2 &

sleep 2

DISPLAY=:2 fluxbox &

sleep 2

DISPLAY=:2 exec java-app

[fenugrec]

@zgrim thanks. Had you tried the other workaround by editing ~/.config/icewm/winoptions as described above ?

[zgrim]

@fenugrec yes, i tried ignoreNoFocusHint, and combinations with other options, it didn't work for me, the app still loses focus on workspace switching, whatever i try. It actually half-loses it, the window is focused, but the caret in the text area disappears, i have to click it to be able to type.

[zgrim]

The following questionable patch fixed my java (intellij) IDE focus issues, for now, HTH.
Somewhat better than the Xnest hack above, dunno what may break, i've had no surprising side-effects with it yet.

diff --git a/src/yxapp.cc b/src/yxapp.cc
index 3c624168..1ff2fd9d 100644
--- a/src/yxapp.cc
+++ b/src/yxapp.cc
@@ -867,7 +867,9 @@ void YXApplication::saveEventTime(const XEvent &xev) {
     }
 }

-Time YXApplication::getEventTime(const char *) const {
+Time YXApplication::getEventTime(const char *ev) const {
+    if (ev && !strcmp(ev, "sendTakeFocus"))
+        return CurrentTime;
     return lastEventTime;
 }

[gijsbers]

This goes against the ICCCM standard:

Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property may receive a
ClientMessage event from the window manager (as described in section 4.2.8) with
WM_TAKE_FOCUS in its data[0] field and a valid timestamp (i.e., not CurrentTime) in its
data[1] field.

A.7. Version 2.0, April 1994

Window managers are now prohibited from placing CurrentTime in the timestamp field of
WM_TAKE_FOCUS messages.

So if the hack works for you, then you really need to contact the developers of your application.

[zgrim]

This goes against the ICCCM standard

Yes, i'm aware this isn't a proper fix, didn't want to imply that it is.

So if the hack works for you, then you really need to contact the developers of your application.

What's a bit off about it is that this focus issue doesn't happen in fluxbox (or openbox, etc), which raises the chances of it being an icewm thing. Hard to tell, i know, these java gui apps carry some historical mishaps in this area, but in this particular case it might be the WM.
For example, fluxbox does the same (proper) thing, i.e. doesn't use CurrentTime, but it works fine there. 🤷

https://github.com/fluxbox/fluxbox/blob/88bbf811dade299ca2dac66cb81e4b3d96cfe741/src/WinClient.cc#L201-L202

[gijsbers]

raises the chances

If you buy a lottery ticket it raises the chances of getting rich.

it works fine there.

If you drive on the right side of the road you reach your destination, but if you drive on the wrong side of the road you bump into things, so let's fix the wrong side of the road.

You really need to contact the developers of your application.

[gijsbers]

commit a1fdb8b is an attempt to help solve this. If you like you could test this and see if it works for you?

[fenugrec]

Thanks !
will try to compile and run on next reboot, but that will be in ~ 1 week. [EDIT - compiled just now, but will still be unable to test for a few days]

[zgrim]

Thank you!
For me, this branch fixes the focus issue (yay!) but breaks ModSuperIsCtrlAlt=1.
This seems to be from 579fed7, it works with that one reverted.
I mean using left super + [0-9]/arrows to change workspaces instead of Ctrl+Alt+[:digit:]/arrows.

[gijsbers]

Your testing was most helpful! I believe this fixes the ModSuperIsCtrlAlt=1.

[zgrim]

I believe this fixes the ModSuperIsCtrlAlt=1.

It does, thank you!