Bug 347153

Same issue with NetBeans.

openSUSE 13.2 x86_64
kwin_x11 5.3.90
plasma 5.3.90

Same issue with both tn5250j & Squirrel-SQL
Kubuntu 15.04
kwin 4:5.2.2a-0ubuntu1
plasma-workspace 4:5.2.2-0ubuntu3

The most important information is probably whether it's OpenJRE or Oracle java.

On top of that the window gets activated (as you suggest) and that means kwin will pass it the focus as well, the problem will then be that either swing bounces the focus or keeps some silly internal focus flag.

Wild guess:
Does it also happen with the compositor suspended  (SHIFT+Alt+F12)
If not, what if you run "kcmshell4 kwincompositing" (resp. "kcmshell5 kwincompositing") and set the thumbnail keeping to never.

Assuming I'm correct on this hunch:
We might need a rule or detect and blacklist java clients for more fine grained control on this.

I'm running OpenJDK 1.8.0. There is a guy in the forum thread I linked and he claims that he tried Oracle JDK and the result was the same (https://forum.kde.org/viewtopic.php?f=289&t=121941#p315281).

Disabling the compositor has no effect on this. The issue remains even with the compositor disabled.

updateXTime() issue - the client refuses the focus (by the WM hint) but participartes in the WM_TAKE_FOCUS protocol (via a client message)

The client message is then sent w/ an outdated xtime, the client sees that, thinks "naaaahhhhh..." and doesn't take the focus.

We could require to always send client messaged on updateXTime() or XCB_CURRENT_TIME.

https://git.reviewboard.kde.org/r/123639/


This is somewhat related to bug #343430

I have the same issue with WebStorm, IntelliJ idea running any JVM: 
* java-8-jdk
* java-8-openjdk
* java-7-openjdk

I didn't found any good workaround.

There's no usable workaround for this.
Forcing java clients to accept the focus from the WM will make them freaky and behave somewhat random.

You'll have to wait for 5.3

"5.3.1" ....

It's good to hear that the solution is on its way! Can you give us any ETA?

https://techbase.kde.org/Schedules/Plasma_5 ;-)
It's not known when your distro ships the update, though - sorry.

Git commit c2ba7658208ff50eed350cfa6f4dd44f2db77a81 by Thomas Lübking.
Committed on 15/05/2015 at 19:58.
Pushed by luebking into branch 'Plasma/5.3'.

updateXTime before sending a takeFocus message

old timestamps confuse clients
REVIEW: 123639

M  +3    -1    client.cpp

http://commits.kde.org/kwin/c2ba7658208ff50eed350cfa6f4dd44f2db77a81

Git commit 77047aa555c8ed58e8fc21c3f573b42d0c05a59b by Thomas Lübking.
Committed on 15/05/2015 at 21:55.
Pushed by luebking into branch 'master'.

updateXTime before sending a takeFocus message

old timestamps confuse clients
REVIEW: 123639

M  +3    -1    client.cpp

http://commits.kde.org/kwin/77047aa555c8ed58e8fc21c3f573b42d0c05a59b

*** Bug 348034 has been marked as a duplicate of this bug. ***

*** Bug 348127 has been marked as a duplicate of this bug. ***

I have just updated to 5.3.1 and after some initial testing, the bug seems to be fixed. Thanks guys for the great work!

Just updated to 5.3.1, and I confirm what Tobiáš Potoček said. 
The "bug" seems to be fixed. (tested with WebStorm, IntelliJ Idea).
Thanks for the work :)

It seems some of focus loosing come back again to NetBeans (8.0.2). Ok, when switching to it:
+ with mouse
+ with mouse on panel
+ from one desktop to another
+ on minimizing or closing of another app
Not ok, when:
- using Alt+(Shift)+Tab
- sometimes in NetBeans dialog and tool windows ("Implemented/Overriden in", "Generate")

I'm using openSUSE 13.2 x86_64, Plasma5 & KF5 from KDE:Unstable:Frameworks (git).

Since it's the very same code path, there might be an issue because of the tabbox window?
Do you use one? What if you use cover/flipswitch or just show the selected window instead?
(kcmshell5 kwintabbox)

I have Breeze kwintabbox effect, but switching it off (and/or even showing selected window) has no effect.

Happens.
I kinda suspect the tabbox input grab to be the cause.

Since you're using git, did it work until eg. before https://git.reviewboard.kde.org/r/125392/ ie. around a week ago? (the patch doesn't deal with activation but maybe I removed an implicit tiem update)

Fwwi, this "works", but is oc no acceptable patch:

diff --git a/tabbox/tabbox.cpp b/tabbox/tabbox.cpp
index 5485911..2d17838 100644
--- a/tabbox/tabbox.cpp
+++ b/tabbox/tabbox.cpp
@@ -1435,7 +1435,8 @@ void TabBox::accept(bool closeTabBox)
     if (closeTabBox)
         close();
     if (c) {
-        Workspace::self()->activateClient(c);
+        QTimer::singleShot(100, c, [c]{ Workspace::self()->activateClient(c); });
+//         Workspace::self()->activateClient(c);
         shadeActivate(c);
         if (c->isDesktop())
             Workspace::self()->setShowingDesktop(!Workspace::self()->showingDesktop());

0ms single shot works as well (sorry for the spam)

And finally using XCB_TIME_CURRENT_TIME instead of xTime() in Client::sendClientMessage() works as well (ungrabXKeyboard() uses XCB_TIME_CURRENT_TIME)

I suspect this to be related to our recent fun with the Alt+F3 menu failing to grab input...

I tried to xcb_flush() right after the ungrab, but that doesn't help.
Nevertheless it smells like xcb or "something" resorts events depending on the timestamp and always moves XCB_TIME_CURRENT_TIME to the end??

I am able to reproduce it with Android Studio and Netbeans.

The applications sometimes (very rarely) regain focus when I switch to another desktop and then almost instantly switch back.

kwin 5.5.3
plasmashell 5.5.3
KDE Frameworks 5.17.0
Arch Linux

"switch back" to what?
The desktop switching related case should actually be caught, only the tabbox case is open (comment #21 and #23)

=> Can elaborate on the behavior?

Sorry, I meant switching back to the previous desktop.

So, the following works fine:
* switching between desktops by clicking/scrolling on the pager
* switching between windows with Alt+Tab (tried Cover Switch, Flip Switch and Breeze)
* switching between windows by clicking/scrolling on the task manager (even when they are on different desktops)
* minimizing/closing another application

I also didn't notice any problems with dialog and tool windows in Netbeans.

The only thing that doesn't work is switching between desktops with hotkeys (Ctrl+Alt+Left/Right).

What gets the focus on the old desktop - some Java client or something else?
Do you show a desktop indicator on switching VDs and does that matter? (kcmshell5 desktop, "switching" tab, option to show an osd)

Nothing, there are no focused windows, even if non-Java applications are present on this desktop.
No, desktop indicator is not enabled and enabling it doesn't help.
The value of desktop effect animation also doesn't matter.

It seems, though, that when the indicator is enabled, the window gets focus a bit more often when I switch between desktops very quickly. When I do it slower, focus is always lost.

This sounds as if the client would not only reject the focus, but also feel oblieged to "revert" the virtual desktop change (which was totally not caused for the focus change, of course...)

Does it "fix" if you setup a client rule (Alt+F3, "special application setting") to forcefully accept the focus (last tab)?
(Java might not "understand" that it now has the focus, so be prepared that while the window might activate, you won't be able to type into it ...)

Yes, when "Accept focus" is set to "force", the window does receive focus. But, just as you said, I'm unable to type anything.

*Sigh*
https://git.reviewboard.kde.org/r/126753/

For the records, oracle or open jdk?

(In reply to Thomas Lübking from comment #32)
Exactly the same situation as Roman Teterin on Oracle JDK

Fedora fc23.x86_64
kwin_x11 5.5.3
plasmashell 5.5.3

Git commit e73e331f35b9da4bbb99c80c5c1eedd2ae99422b by Thomas Lübking.
Committed on 15/01/2016 at 21:00.
Pushed by luebking into branch 'master'.

use XCB_CURRENT_TIME for NET::TakeFocusProtocol

The only clients that really seem to rely on it are
Java and they're apparently "broken", resp. extremely
picky on the tiemstamp and probably happily refuse focus
if it's *not* equal to the current server time (ie. anything else
happens at this moment) and overmore feel oblieged to act as WM
by juggling around VDs at all.
FIXED-IN: 5.6
REVIEW: 126753

M  +3    -4    client.cpp
M  +2    -1    client.h

http://commits.kde.org/kwin/e73e331f35b9da4bbb99c80c5c1eedd2ae99422b

I have OpenJDK.

The patch works, thank you.

Hey guys, when is the latest patch going to be included into upstream? I just updated to 5.5.4 and the problem as described above (Java software losing focus when switching desktops using hot keys) is still present.

5.6.0 - despite the impact is very likely limited to java, it's indeed "wrong" and open for regressions => next minor release

5.6.1 - it's still there...

Still experiencing this as well on Kubuntu 15.10 latest patch level; I run both RubyMine and PhpStorm throughout my average day and every time I move back to the virtual desktop I run them on, they are always unfocused when I reach that virtual desktop.  I only run one of those two programs at a time on that virtual desktop (ie., the only window present.)

I'm experiencing this on KDE Plasma 5.20.5, KDE Frameworks 5.78 with the latest stable releases of JetBrains IDE family such has PyCharm 2020.3.3 and Android Studio 4.1 .

Created attachment 148992 [details]
Native reproducer

The problem wasn't reproducible with Plasma 5.18.8 (in Kubuntu 20.04.4), but is reproducible again with Plasma 5.24.4 (in Kubuntu 22.04) and 5.24.5.

I believe, it's a regression after https://bugs.kde.org/show_bug.cgi?id=421068.

The previous discussion mentions that it could be a problem with client code (Java implementation in particular), but I think that, now at least, this is a KWin issue, affecting 'globally active' (in ICCCM terms) clients in general. As a justification, and as a tool to investigate the issue, I'm attaching source code for a simple native 'globally active' focus client application (see focusTest.c). All it does is changes the window background on receiving and losing focus. To reproduce the issue, focus the test app, then use Alt+Tab to switch to an application in a different virtual desktop (filtering by virtual desktops should be disabled in task switcher settings), then Alt+Tab back. The window won't be focused as expected - with background rendered in white.

Judging from xtruss-generated logs, KWin does send WM_TAKE_FOCUS message to the client, and the client, in turn, requests focus on its window using SetInputFocus, but the request isn't satisfied by the X server. This can be due to only one reason - an 'old enough' timestamp passed. As the client just uses the timestamp received in WM_TAKE_FOCUS message, KWin must be sending the stale timestamp in the described case.

It may be interesting that I can trigger this issue only if I switch desktop back and forth via keyboard shortcut. There is no problem if pager widget is used.

@Dmitry Batrak: FYI https://invent.kde.org/plasma/kwin/-/merge_requests/3465