Libreoffice does not get focus when opening new window in existing instance

[PetteriAimonen]

Steps to reproduce:

1. Start lowriter and observe the splash screen appear and the window gets focus.
2. Focus two other windows, so that you get window manager events that do not involve the lowriter window.
3. Start lowriter and observe no splash screen (because there is existing instance) and that the new window does not get focus.

Based on git bisect, this behavior started after icewm commit 0499fce.

However I'm not sure if it is icewm or libreoffice bug.
Checking the timestamps it seems that libreoffice is taking the userTime for its new window from the last event its existing instance has received.

# Window events involving other programs happen, window manager user time gets updated
21:36:03  YFrameClient::getUserTime 0x5617a55d7d30 2331641134
21:36:03  YWindowManager::updateUserTime 2331641134

# Libreoffice window opens, it has _NET_WM_USER_TIME_WINDOW set and that window has old timestamp
21:36:06  UserTimeWindow 2331637953
21:36:06  YFrameClient::getUserTime 0x5617a5627240 2331637953

# The timestamp from libreoffice is 4 seconds in the past from managerTime, 7 seconds past in real time 
21:36:06  updateFocusOnMap client=0x5617a5627240 userTime=2331637953 managerTime=2331641134 doActivate=0

# After clicking on the libreoffice window it gets new time
21:36:20  UserTimeWindow 2331657463
21:36:20  YFrameClient::getUserTime 0x5617a5627240 2331657463

The libreoffice window has _NET_WM_USER_TIME_WINDOW set and icewm appears to be using it.
Prior to 0499fce this apparently didn't work correctly, so in a sense icewm is now working properly.

I have confirmed that if I disable the check for getUserTimeWindow() in YFrameClient::getUserTime(), then libreoffice gets focus correctly.
Presumably because the libreoffice main window does not have user time and then icewm just always gives the focus.

But I'm still confused why libreoffice works ok with other window managers.

[gijsbers]

Thanks for your work.

When another lowriter is started from the command line, it indeed carries the same user_time. Repeated command line lowriters copy it.

Contrast this with the first lowriter. As long as it has not yet received input, it doesn't have a user_time.

Maybe the LO devs can shed light on this contradiction?

Why other WMs (which?) focus it is indeed intriguing.

Strangely there isn't a winoption to overrule this and enforce focus.

[gijsbers]

According to https://specifications.freedesktop.org/wm/latest/ar01s05.html#id-1.6.16

Clients should set this property on every new toplevel window
(or on the window pointed out by the _NET_WM_USER_TIME_WINDOW
property), before mapping the window, to the timestamp of the
user interaction that caused the window to appear.

...

Clients can obtain the timestamp that caused its first window
to appear from the DESKTOP_STARTUP_ID environment variable,
if the app was launched with startup notification. If the client
does not know the timestamp of the user interaction that caused
the first window to appear (e.g. because it was not launched with
startup notification), then it should not set the property for that window.

LO is non-conformant.

[PetteriAimonen]

Looks like many window managers don't even bother with user time anymore, and just focus any window regardless of user interaction time.

Maybe icewm also should have a setting like FocusOnMapAlways or FocusOnMapIgnoreUserTime. It seems like a legitimate behavior someone may want, and a useful workaround for these bugs.

[gijsbers]

Looks like many window managers

is misleading, because what is many and which ones? Above I also asked which? without reply. Because there are so many and because they vary so wildly, such statements are always true and therefore meaningless and confusing. Try to say things that are verifiable true, if possible.

[PetteriAimonen]

You are correct to demand more precision.

Turns out XFCE4 xfwm4 does support _NET_WM_USER_TIME for focus stealing prevention, but it has to be turned on in the "Window Manager Tweaks" -> "Focus" -> "Activate focus stealing prevention". When that activated, the same libreoffice bug occurs.

Similarly when setting KWin "Focus stealing prevention" to "High" or larger. Edit: Meh, looks like at "High" any new application window does not get focus on KWin, so that's different behavior.

So the difference is really only in the window manager configuration. KWin defaults to "Low" and xfwm4 defaults to no focus stealing prevention, while icewm has focus stealing prevention always active.

[PetteriAimonen]

The deeper I dig, the more confused I get.

Using the exact same version of libreoffice in a Debian 13 KDE livecd, it seems to set _NET_WM_USER_TIME instead and appears to do so correctly, and focus works even in IceWM. But on my main Debian 13 installation it instead sets _NET_WM_USER_TIME_WINDOW and the window has wrong timestamp.

Turns out installing libreoffice-gtk3 changes it to use _NET_WM_USER_TIME_WINDOW instead. I can confirm that on my system the wrong behavior stops after I uninstall libreoffice-gtk3 package, though then I lose the gtk widget styling. But installing libreoffice-qt5 and setting SAL_USE_VCLPLUGIN=qt5 works ok enough.

(Installing libreoffice-gtk4 and enabling it with SAL_USE_VCLPLUGIN=gtk4 causes libreoffice to crash totally..)

But yeah, seems like deep enough libreoffice issue that not much can be done in icewm to really fix this. An option to disable focus stealing prevention could be a nice-to-have.

I'm closing this off as switching libreoffice to qt is good enough workaround.

[gijsbers]

Thanks again. This then looks like a bug in gtk3 to me. In this forum I have seen so many gtk bugs that it doesn't surprise me. They don't seem to care too much about EWMH conformance.

As I said above:

Strangely there isn't a winoption to overrule this and enforce focus.

This is still a valid option for me. The only worrying question is: is libreoffice-gtk3 the main reason? If so, it seems logical to give them a bug report.

[PetteriAimonen]

Yeah, I think the main reason for an option would be to work around buggy apps. I wouldn't be surprised if there are other ones.

I did look at possibly filing bug against libreoffice-gtk3, but it seems they are porting to gtk4 now. So perhaps it is waste of resources even on libreoffice side going chasing after this. The gtk3 backend seems to target mostly gnome, on which focus stealing prevention is work-in-progress. Their interest might be more in Wayland.

[gijsbers]

Can you test this?

[PetteriAimonen]

Thanks, I confirm that after updating to latest git version and running:

icewmhint libreoffice ignoreUserTime 1

libreoffice starts getting focus correctly even with the gtk3 backend.