Pop-Up not getting the focus

[gprints]

This is kind of hard to describe, but the preferences file is very simple:

PingTimeout=10
TimeFormat="%R"
WorkspaceNames=" 1 ", " 2 ", " 3 ", " 4 "
TaskBarShowAPMAuto=0 # 0/1
TaskBarShowMailboxStatus=0 # 0/1
TaskBarShowWindowListMenu=0 # 0/1
TaskBarShowCPUStatus=0 # 0/1
TaskBarShowMEMStatus=0 # 0/1
TaskBarShowCollapseButton=1 # 0/1
PagerShowPreview=0 # 0/1
ShowThemesMenu=0 # 0/1
ClickMotionDistance=8 # [0-32]
ClickMotionDelay=400 # [0-2000]

After "some time" , there's a change in behaviour. In the beginning everything works fine. At some point, newly created windows don't get the focus. I've seen it on FreeBSD 13.5-RELEASE-p5 on x64 with 3.9.0, the official package from poudriere-git-3.4.3 and it happened in a self-compiled Seamonkey. But I've also seen it happening with Red Hat Enterprise Linux 8.10 on x64 with 3.8.0-2, also the official icewm package there and the official thunderbird binary as application. What happens is, you press the del key and the "are you sure" window does not have focus, so pressing Return will open the message in a new window. Or you click on "reply" and the editor window does not get focus, so whatever key you press ends up doing something the the message.
I can get the behaviour back to normal by "chosing restart icewm" from the logout menu. After that, it takes "some time" before it comes back. I'd say "some time" is several days. There is no change to the "Preferences, Focus" menu.

[gijsbers]

Do you use click-to-focus? Can you reproduce it with sloppy mouse focus or quiet focus?
Does this apply only to transient windows? That is, helper windows that accomplish a subfunction? You can use xprop on that window to see if it has a WM_TRANSIENT_FOR property. Also the WindowList Window shows such windows in an indented tree.
If "some time" is several days, it is difficult to reproduce. Can't stand click-to-focus that long.

[gprints]

It does not only affect transient windows. I'll try playing with the focus options.

[gprints]

While I do not yet know whether it occurs with sloppy focus enabled, once I have it in click focus, switching to sloppy does not fix it.

[gijsbers]

Good. We need to figure out one question: is it dependent on the type of window as determined by its properties or not. You say it affects popup windows, but a popup window can also be a normal window or not.

[gprints]

I just got it with focus set to sloppy. It seems to show in certain applications only, though. Nedit and LibreOffice work fine, Firefox, Seamonkey and Gimp are affected. My gimp is sill using gtk 2, Firefox is using gtk 3 (3.24.50).

gimp_does_show_the_bug.xprop.txt
seamonkey_does_show_the_bug.xprop.txt
libreoffice_does_not_show_it.xprop.txt
firefox_does_show_the_bug.xprop.txt
nedit_does_not_show_the_bug.xprop.txt

And while LibreOffice is fine (using Qt5), OpenOffice is affected (using gtk 2.24.33).

open_office_after_icewm_restart.xprop.txt
open_office_does_show_the_bug.xprop.txt

[gijsbers]

Good data! The _not_ have _NET_WM_STATE(ATOM) = _NET_WM_STATE_MODAL.

[gijsbers]

Restarting the application doesn't help? All the _does_ applications start being affected at the same time?

[gprints]

I got all xprops by starting the applications after I saw the bug. But I think it also happens while they are running. I've never seen this before icewm 3.8.0.

[gijsbers]

In other words, it was introduced after 3.7.5.

[gijsbers]

Between 3.7.5 and 3.8.0 no possible cause could be found.

A few minor versions before that some refinements to handling of USER_TIME were introduced, to improve focusing. That could be a potential cause.

The USER_TIME is about the last event time of user input to an application. You can get a first impression by the following script that prints the usertime for new windows:

icesh x11time -a list usertime x11time  ; icesh -Await list usertime x11time loop

[gprints]

I don't know the version jump on FreeBSD, on Linux I went from 3.4.7 or lower to 3.8.0. I have no idea what to look for with that USER_TIME, but here's what it looks like with the bug:

icesh x11time -a list usertime x11time ; icesh -Await list usertime x11time loop
2889941957
[removed long list of windows]
0x2600008 _NET_WM_USER_TIME = 2650344020
0x0a00066 _NET_WM_USER_TIME = 2889937213
2889941963
0xa000b9 0 81260 "Compose: (no subject)": (Msgcompose.SeaMonkey) 584x997+1010+26
0x0a000b9 _NET_WM_USER_TIME = 2889955205
2889955430

I can only see the missing 0 in 0xa000b9 being special, but I suppose it's just the formatting and internally it's an integer. And apparently nedits and xterms do not have _NET_WM_USER_TIME.

Without the bug - and two more open windows - it looks like this:

icesh x11time -a list usertime x11time ; icesh -Await list usertime x11time loop
2890917467
[removed long list of windows]
0x2600008 _NET_WM_USER_TIME = 2650344020
0x240001e _NET_WM_USER_TIME = 2890148571
0x2400048 _NET_WM_USER_TIME = 2890588957
0x2000003 _NET_WM_USER_TIME = 2890823897
2890917484
0x24000e3 0 82032 "Compose: (no subject)": (Msgcompose.SeaMonkey) 584x997+1010+26
0x24000e3 _NET_WM_USER_TIME = 2890922720
2890922965

[gijsbers]

Are you maybe willing to pinpoint the exact version? For example, start from 3.7.1 and go up or down depending if its good or buggy. Or use git bisect.

[gprints]

On Linux I went from icewm 3.4.2 to 3.8.0, but that was in October 2023. I'm pretty sure I did not have the bug in 2024, which makes me think that it wasn't a change to code in icewm itself, maybe a library instead or something that changed behaviour of gtk2 and gtk3 applications, which would explain why it does not affect Qt. Unfortunately, I don't remember when I encountered it for the first time. But on the other hand, the gtk2 and gtk3 in the Linux machine haven't changed since 2021.

[gijsbers]

Since 3.4.2 there are 600 commits, so its too large a haystack to find the needle.