When LibreOffice is launched, the window displayed is inactive and behind all other windows. New dialogs (e.g. Print..., Save As..., Convert to PDF) are inactive when displayed. This is LibreOffice v. 4.3.3.2, kwin v. 4.11.12, and KDE v. 4.14.1. Attached: KWin rules, in order, with "1.kwinrule" being the top and "5.kwinrule" at the bottom. None have an effect on LibreOffice specifically. Reproducible: Always Steps to Reproduce: 1. Open LibreOffice or a LibreOffice dialog. Actual Results: Window is inactive Expected Results: Window should be active URL is a video displaying this behavior. There is a rule in effect where inactive windows are semi-transparent and active windows are opaque. Video: https://www.copy.com/s/ZOtTj31FkSCeDLfy/Screencast%202014-11-12%2020%3A44%3A54.mp4
Created attachment 89569 [details] kwin window rule #1
Created attachment 89570 [details] kwin window rule #2
Created attachment 89571 [details] kwin window rule #3
Created attachment 89572 [details] kwin window rule #4
Created attachment 89573 [details] kwin window rule #5
When window rules list is clear, the bug is still present
please post the output of "qdbus org.kde.KWin /KWin supportInformation", resp. what's your focus stealing prevention level and what happens if you set it to "low" resp. "none" run "kcmshell4 kwinoptions" for configuration
Created attachment 89622 [details] Output of `qdbus org.kde.KWin /KWin supportInformation`
Same behavior with focus stealing prevention level set to "none". Output of `qdbus org.kde.KWin /KWin supportInformation` attached.
That would imply that LibreOffice sets a usertime of "0" (which is an explicit hint to not get the focus) Unfortunately that's hard to debug unless you can recompile kwin w/ an explicit debug statement?
(In reply to Thomas Lübking from comment #10) > That would imply that LibreOffice sets a usertime of "0" (which is an > explicit hint to not get the focus) > Unfortunately that's hard to debug unless you can recompile kwin w/ an > explicit debug statement? Should I report something against LibreOffice then?... I am more than willing to recompile kwin but am unsure of what additional options I would have to pass.
(In reply to searchfgold67899 from comment #11) > I am more than willing to recompile kwin but am unsure of what additional > options I would have to pass. No problem: diff --git a/activation.cpp b/activation.cpp index 9662f32..f7e3061 100644 --- a/activation.cpp +++ b/activation.cpp @@ -557,7 +557,10 @@ bool Workspace::allowClientActivation(const KWin::Client *c, xcb_timestamp_t tim ac = last_active_client; } if (time == 0) // explicitly asked not to get focus + { + qDebug() << "Client refuses focus" << c; return false; + } if (level == 0) // none return true; if (level == 4) // extreme > Should I report something against LibreOffice then?... Let's see whether this is the case. In case: yes. (Maybe a java/swing/awt issue, though)
> > Should I report something against LibreOffice then?... > > Let's see whether this is the case. In case: yes. (Maybe a java/swing/awt > issue, though) I just got this reported in private for Firefox and tried it and yes, I got: User timestamp, ASN: 0 User timestamp, final: 'ID: 29433370 ;WMCLASS: "iceweasel" : "navigator" ;Caption: "Iceweasel" ' : 0 !!!!!!!!!!!!!!!!! Client refused focus 'ID: 29433370 ;WMCLASS: "iceweasel" : "navigator" ;Caption: "Iceweasel" '
Just an update on testing with Firefox. For a new window we get: _NET_WM_USER_TIME(CARDINAL) = 0 _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1c19645 Interesting here is that KWin doesn't support _NET_WM_USER_TIME_WINDOW and also that the window does not have any properties at all. Of course it's possible that there is a bug with our startup notification handling, but then Firefox should delete the property.
There is some wrongness in kdeinit-kstartupnotification interaction with lots of warnings in xsession-errors. The following patch fixes those warnings: diff --git a/src/kxmessages.cpp b/src/kxmessages.cpp index 2e625d2..c5a32fd 100644 --- a/src/kxmessages.cpp +++ b/src/kxmessages.cpp @@ -216,7 +216,7 @@ bool KXMessages::broadcastMessageX(Display *disp, const char *msg_type_P, if (disp == NULL) { return false; } - if (!QX11Info::isPlatformX11()) { + if (QCoreApplication::instance() && !QX11Info::isPlatformX11()) { qWarning() << "KXMessages used on non-X11 platform! This is an application bug."; return false; } explanation: kdeinit is not creating a Q(Core)Application thus our check always failed.
> Interesting here is that KWin doesn't support _NET_WM_USER_TIME_WINDOW and also that the window does not have any properties at all. I can confirm that for firefox (33.1.1). At least here, LO however doesn't show this behavior. Also FF has a sane _NET_WM_USER_TIME on the actual window (which proposed _NET_WM_USER_TIME_WINDOW) a) I assume FF and LO are not related in this regard b) I assume FF acts "correctly" here - though it promotes _NET_WM_USER_TIME_WINDOW, it understands that this is not supported by the WM and sets _NET_WM_USER_TIME on the actual window > There is some wrongness in kdeinit-kstartupnotification interaction with lots of warnings in xsession-errors. Notice that the original bug is against KWin 4.11.12, not 5 > - if (!QX11Info::isPlatformX11()) { > + if (QCoreApplication::instance() && !QX11Info::isPlatformX11()) { Why would esp. a Q*Core*Application be required, given that the function takes a display as first parameter? Isn't it more likely that *disp is junk (resp. nullptr)? I'd rather expect trouble if KXMessages::broadcastMessage(const char *msg_type_P, const QString &message_P, int screen_P) was invoked before constructing a QGuiApplication instance (to obtain appRootWindow() etc.)
On Thursday 20 November 2014 19:22:56 you wrote: > Why would esp. a Q*Core*Application be required, given that the function > takes a display as first parameter? > Isn't it more likely that *disp is junk (resp. nullptr)? The code in question got called from kdeinit.cpp (kdeinit framework) which is not using a Q*Application, thus the check calling into the QPA always returned false and the message got never broadcasted. Adding the check for QCoreApplication::instance is for keeping the behavior of emitting a warning if the message is mis-used, though one can argue (and I will do that with myself) whether the check is completely wrong.
Comment from GCI student: I use Ubuntu 14.10 with KDE 4.14.2, KWin and LibreOffice are the same version as you. I have no problem window is active
This is most likely sth. in the particular LO The only ways to get an inactive window w/ FSP set to "none" are a) LO hints a usertime "0" b) the currently active window bounces its usertime like hell (ie. it would depend on the currently active window, what does not comply w/ the inactive dialog while LO actually has the focus) A 3rd candidate could be the autohiding launcher. searchfgold67899, you could try to #!/bin/sh export SAL_USE_VCLPLUGIN=gen in an executable script in ~/.kde/env (maybe ~/.kde4/env) This should force LO to start w/o the KDE integration module (which is not available from my distro)
I have the same focus problem with LO on my system: Arch linux - 3.17.6-1-ARCH KDE 3.14.3 LO - 4.2.8.2 This problem has started this year, as usual after update, unfortunately I don't remember exactly date, but currently I work more with LO and it's really annoying. I tried to set "export SAL_USE_VCLPLUGIN=gen", doesn't help. LO has changed it's view, but not focus behavior changes. I tried to set kde rules for LO windows also, "steal focus" settings, doesn't change enything.
Bug in LibreOffice for pretty much sure. See also: https://forum.kde.org/viewtopic.php?f=66&t=123993&hilit=libreoffice https://www.libreoffice.org/bugzilla/show_bug.cgi?id=75471
(In reply to Thomas Lübking from comment #21) > Bug in LibreOffice for pretty much sure. > > See also: > https://forum.kde.org/viewtopic.php?f=66&t=123993&hilit=libreoffice > https://www.libreoffice.org/bugzilla/show_bug.cgi?id=75471 It happens with Audacity, too.
(In reply to Thomas Lübking from comment #19) > This is most likely sth. in the particular LO > > The only ways to get an inactive window w/ FSP set to "none" are > a) LO hints a usertime "0" > b) the currently active window bounces its usertime like hell (ie. it would > depend on the currently active window, what does not comply w/ the inactive > dialog while LO actually has the focus) > > A 3rd candidate could be the autohiding launcher. > > searchfgold67899, you could try to > > #!/bin/sh > export SAL_USE_VCLPLUGIN=gen > > in an executable script in ~/.kde/env (maybe ~/.kde4/env) > This should force LO to start w/o the KDE integration module (which is not > available from my distro) Your script placed in ~/.kde/env (which existed). Rebooted and the software was still behaving as it was before.
(In reply to searchfgold67899 from comment #22) > It happens with Audacity, too. Which window/dialog in particular? Did you try whether it (or OOo) actively refuses the focus? (comment #12)
(In reply to searchfgold67899 from comment #23) > (In reply to Thomas Lübking from comment #19) > > This is most likely sth. in the particular LO > > > > The only ways to get an inactive window w/ FSP set to "none" are > > a) LO hints a usertime "0" > > b) the currently active window bounces its usertime like hell (ie. it would > > depend on the currently active window, what does not comply w/ the inactive > > dialog while LO actually has the focus) > > > > A 3rd candidate could be the autohiding launcher. > > > > searchfgold67899, you could try to > > > > #!/bin/sh > > export SAL_USE_VCLPLUGIN=gen > > > > in an executable script in ~/.kde/env (maybe ~/.kde4/env) > > This should force LO to start w/o the KDE integration module (which is not > > available from my distro) > > Your script placed in ~/.kde/env (which existed). Rebooted and the software > was still behaving as it was before. I take this back, because after another reboot, LibreOffice now displays windows focused correctly.
(In reply to searchfgold67899 from comment #25) > (In reply to searchfgold67899 from comment #23) > > (In reply to Thomas Lübking from comment #19) > > > This is most likely sth. in the particular LO > > > > > > The only ways to get an inactive window w/ FSP set to "none" are > > > a) LO hints a usertime "0" > > > b) the currently active window bounces its usertime like hell (ie. it would > > > depend on the currently active window, what does not comply w/ the inactive > > > dialog while LO actually has the focus) > > > > > > A 3rd candidate could be the autohiding launcher. > > > > > > searchfgold67899, you could try to > > > > > > #!/bin/sh > > > export SAL_USE_VCLPLUGIN=gen > > > > > > in an executable script in ~/.kde/env (maybe ~/.kde4/env) > > > This should force LO to start w/o the KDE integration module (which is not > > > available from my distro) > > > > Your script placed in ~/.kde/env (which existed). Rebooted and the software > > was still behaving as it was before. > > I take this back, because after another reboot, LibreOffice now displays > windows focused correctly. Now, some windows display correctly (Print, Help), while others do not (Save).
Actually I can (now?) reproduce it pretty much reliably w/ the print dialog. I could not spot a pattern in when it works and when not, but I can assure that when it does not get the focus, that's because: _NET_WM_USER_TIME(CARDINAL) = 0 It *explicitly* asks to not get it. => That's a client bug for sure (the proeperty on the window isn't updated later on either, so this is not about a forgotten XSync() or something) I'll open a RR to invoke the rules here, so that you can override this by setting accept focus to "apply initially" "true", but that will only be available in 5.3 --- Could not reproduce w/ audacity so far.
-> https://git.reviewboard.kde.org/r/122195/
Git commit 6957e1cf1ad5278e7d02daaf95a4bd2c4f10c858 by Thomas Lübking. Committed on 22/01/2015 at 00:11. Pushed by luebking into branch 'master'. consult rulebook on honoring a 0 usertime apparently some clients (randomly?) set _NET_WM_USER_TIME to 0 (recorded for libreoffice, audacity and perhaps firefox), so we allow to forcefully have them accept the focus here REVIEW: 122195 M +4 -2 activation.cpp http://commits.kde.org/kwin/6957e1cf1ad5278e7d02daaf95a4bd2c4f10c858
Hi Thomas, I am having this problem on OpenSUSE 13.2 with KDE 4..14.8. That is, LibreOffice windows do not have focus when opened and are always opened in the background. So, my question is: Has this patch been applied to KDE 4 and how do you recommend that I get this patch for KDE 4.14.8? Thanks, Gordon
KDE4 is feature frozen (for quite some time) so only security fixes can go upstream. You'll either have to pick the patch and (hand-)apply it and rebuild KWin or ask your distribution to incorporate it downstream. Please notice that the patch doesn't "fix" anything, because there's nothing "broken" - it will just allow you to setup a window rule for libreoffice to "take focus" despite it explicitly says that it doesn't want it (the actual meaning of the "take focus" rule is a bit different, but it's ok to re-use it here) Ideally, a fix would occur in libreoffice.