Sometimes no focus on new window

[williex]

When a new program is started, icewm sometimes fails to properly focus it. A way for me to reproduce 100%:

1. Start audacious (music player) on desktop 1
2. Press Ctrl+J, an audacious dialog window appears
3. Switch to desktop 2, by keyboard or mouse, doesn't matter.
4. I press the key Ctrl+Alt+a which I have defined as:
   key "Ctrl+Alt+a" xfce4-terminal
   Or I start a terminal from the menu or start a terminal from the quicklaunch, it doesn't matter.
5. The new terminal window does not get focus, it does have the urgency bit set and starts flashing in the taskbar.

The same problem happens with firefox or chromium and seems to happen when there is already a firefox or chromium window running somewhere and a new window is opened.

This problem does not happen in icewm 1.3.8. I've tracked it down to commit a57ec4f. The following patch fixes the problem for me. It's a terrible patch because it completely ignores the new timing code but my X knowledge is too limited to completely understand the code in updateNetWMUserTime

--- icewm-1.3.10.bak/src/wmframe.cc 2015-07-03 03:38:11.000000000 +0200
+++ icewm-1.3.10/src/wmframe.cc 2015-08-15 12:15:08.763321027 +0200
@@ -1851,9 +1851,9 @@
             doActivate = false;
     }

-    if (fUserTime != -1UL)
+/*    if (fUserTime != -1UL)
         if (fUserTime == 0 || fUserTime != manager->lastUserTime())
-            doActivate = false;
+            doActivate = false;*/
 }

 void YFrameWindow::wmShow() {

[bbidulock]

Well, all that does is shut off _NET_WM_USER_TIME support.

_NET_WM_USER_TIME, as far as I understand it, is supposed to work like so:

1. An application that supports _NET_WM_USER_TIME sets the property of the same name on its top-level windows whenever there is user input (key or button) within the application (i.e. it has the focus).
2. When an application that supports _NET_WM_USER_TIME launches, it sets the property on the top-level window to the time of the user interaction that caused the launch. This time is sometimes difficult for the application to determine. Some toolkits will set it to the first X11 protocol timestamp that it obtains during startup, others will use the xdg startup notification id (which contains the timestamp of the event that launched the application). I think I put standard code in icewm to take the timestamp from startup notification and use it if the time is earlier than the timestamp set on _NET_WM_USER_TIME for the corresponding application, or, when _NET_WM_USER_TIME is zero (CurrentTime) or when the application does not support _NET_WM_USER_TIME at all.
3. When the application launches and maps a top-level window, and after reparenting, the WM that supports _NET_WM_USER_TIME will check to see if the initial launch time associated with the new client is older than the latest update to _NET_WM_USER_TIME for existing clients. If it is older, it does not give the window the focus. As a special case, if the application set _NET_WM_USER_TIME to zero (CurrentTime), the window manager should not give the window the focus regardless of the setting of the _NET_WM_USER_TIME property on other windows.

Basically the idea here is that if I type at an xterm:

$> libreoffice &

and then start typing some more, when the main window appears for libreoffice, it should not steal the focus from the xterm while I am actively typing the in the xterm.

Chances are the last != should be a < (in the modulo sense) in the conditional you have commented out.

You can find the specification of _NET_WM_USER_TIME in the EWMH/NetWM specification.

[williex]

Thanks for the thorough explanation. I've tried to run libreoffice in the background like you suggested and with the unpatched/vanilla 1.3.10 release (with _NET_WM_USER_TIME included) the libreoffice window takes focus, even when I keep on typing. So for me the code doesn't seem to be working as intended. Changing != to < did not make a difference.

I also noticed the problem happens when there is already a window of the same program open. So, if I have a firefox window open, sometimes a new firefox window doesn't get focus. But if it's the first firefox window to open, it always gets focus.

I wonder does the net_wm code work for you? If so, it might be something different on my system causing this issue and not something in the icewm code itself.

[sebastianopilla]

I have the same kind of issue on my system (CentOS 7.2 and icewm 1.3.12): when I double-click on a PDF file in my file manager, the PDF reader opens but the title bar is grayed out (the program has no focus) and the taskbar entry flashes.

This happens also for windows for the same program, like in the comment above: for example, in SpaceFM I hit F2 to rename a file and the rename dialog doesn't have focus and the taskbar entry is flashing.

[bbidulock]

Looks like icewm has a lot of focus problems. It is not conforming to ICCCM 2.0. Because focus-setting is strewn around the code under all manner of conditionals, it will take some time and effort to fix.

[bedna-KU]

After I upgrade on IceWM 1.3.12.34 (I dont know previous version) and open sub window aplication, has this subwindow no focus.
Affected applications FileZilla, SpaceFM, Geany, Textadept, Pidgin, HexChat, Medit ...

Roxterm not gained focus at startup in all versions.

I test preferences from mainline and no change.

[bbidulock]

Yes, IceWM is not transfering focus properly, nor does it handle application-modal dialogs properly. Lots of work to fix it (time that I don't have right now).

[bedna-KU]

I have on other computer IceWM 1.3.12.32 and focus work fine. (only roxterm not gained focus)
https://vimeo.com/165105955

[bbidulock]

The issue might be timing related. IceWM is setting focus to window before issuing WM_TAKE_FOCUS command, which is incorrect per ICCCM 2.0 and might be confusing some toolkits but depends on race condition. Unfortunately focus transfer is about 5 levels deep in inheritance and ti is difficult to even establish which code is running.

[PetteriAimonen]

Hmm, is there a missing initialization of fLastUserTime in wmmgr.c? I was printing the timestamps for debugging and was getting garbage values like 0x654b20230a202023, this seems to fix that part:
PetteriAimonen@a6ac9e2

Not sure if it actually fixes the whole problem. Need more time to know, because it starts occurring only approximately once a month for me and usually disappears when I start debugging.

[bbidulock]

Thanks for the patch, @PetteriAimonen

[bedna-KU]

Yes this works OK, thanks @PetteriAimonen.