Bug 347153 - Java app (Netbeans, Intellij IDEA...) window losing focus when switching to another desktop and back
Summary: Java app (Netbeans, Intellij IDEA...) window losing focus when switching to a...
Status: REOPENED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.3.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/123...
Keywords:
: 348034 348127 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-05-04 12:05 UTC by Tobiáš Potoček
Modified: 2023-01-27 20:00 UTC (History)
17 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:
thomas.luebking: ReviewRequest+


Attachments
Native reproducer (1.48 KB, text/plain)
2022-05-19 11:25 UTC, Dmitry Batrak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobiáš Potoček 2015-05-04 12:05:15 UTC
Reproducible: Always

How to reproduce:
1. Open Intellij IDEA and work normally (i. e. start typing something in the editor).
2. Switch to another virtual desktop (i. e. to check something in the browser...)
3. Switch back to the desktop with IDEA and try to continue typing.

Expected result:
After switching back to the original desktop, the IDEA window should regain focus so it is possible to start immediately typing in the editor again.

Actual result:
The window is not focused. I have to interact somehow with the window (click in the window, scroll, Alt-tab) to gain the focus and continue with the work.

I used Intellij IDEA in the example but judging from my experiments it seems that all Swing based software is affected. For instance Eclipse works flawlessly but Netbeans, Intellij software and others don't. But I have tried only a limited set of programs so this might require further investigation.

The bug is quite annoying as it completely breaks my typical workflow: quickly switching between my browser on one desktop and the IDE on another desktop.

Software:
kwin 5.3.0-68.1
plasma 5.3.0-21.1
OpenSuse 13.2

Related links:
https://forum.kde.org/viewtopic.php?f=287&t=121941
http://gsmblog.net/blog/intellij-idea-loosing-focus/ (might be relevant)

Note: there is another bug (https://bugs.kde.org/show_bug.cgi?id=343430) related to Java and problems with focusing but it's a completely different issue.
Comment 1 Mykola Krachkovsky 2015-05-04 14:03:50 UTC
Same issue with NetBeans.

openSUSE 13.2 x86_64
kwin_x11 5.3.90
plasma 5.3.90
Comment 2 Salvador I. Gonzalez 2015-05-04 15:55:49 UTC
Same issue with both tn5250j & Squirrel-SQL
Kubuntu 15.04
kwin 4:5.2.2a-0ubuntu1
plasma-workspace 4:5.2.2-0ubuntu3
Comment 3 Thomas Lübking 2015-05-04 16:04:47 UTC
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.
Comment 4 Tobiáš Potoček 2015-05-04 16:13:05 UTC
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.
Comment 5 Thomas Lübking 2015-05-05 10:39:19 UTC
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
Comment 6 raphael.cazenave 2015-05-07 15:05:45 UTC
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.
Comment 7 Thomas Lübking 2015-05-07 17:17:55 UTC
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
Comment 8 Thomas Lübking 2015-05-07 17:18:09 UTC
"5.3.1" ....
Comment 9 Tobiáš Potoček 2015-05-07 20:12:17 UTC
It's good to hear that the solution is on its way! Can you give us any ETA?
Comment 10 Thomas Lübking 2015-05-07 20:19:43 UTC
https://techbase.kde.org/Schedules/Plasma_5 ;-)
It's not known when your distro ships the update, though - sorry.
Comment 11 Thomas Lübking 2015-05-15 22:16:00 UTC
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
Comment 12 Thomas Lübking 2015-05-15 22:16:43 UTC
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
Comment 13 Thomas Lübking 2015-05-21 07:40:36 UTC
*** Bug 348034 has been marked as a duplicate of this bug. ***
Comment 14 Thomas Lübking 2015-05-23 06:50:52 UTC
*** Bug 348127 has been marked as a duplicate of this bug. ***
Comment 15 Tobiáš Potoček 2015-05-27 06:56:40 UTC
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!
Comment 16 raphael.cazenave 2015-05-27 22:15:49 UTC
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 :)
Comment 17 Mykola Krachkovsky 2015-10-08 09:22:02 UTC
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).
Comment 18 Thomas Lübking 2015-10-08 13:17:31 UTC
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)
Comment 19 Mykola Krachkovsky 2015-10-08 15:33:02 UTC
I have Breeze kwintabbox effect, but switching it off (and/or even showing selected window) has no effect.
Comment 20 Thomas Lübking 2015-10-08 20:46:53 UTC
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)
Comment 21 Thomas Lübking 2015-10-08 21:16:08 UTC
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());
Comment 22 Thomas Lübking 2015-10-08 21:18:02 UTC
0ms single shot works as well (sorry for the spam)
Comment 23 Thomas Lübking 2015-10-08 21:29:58 UTC
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??
Comment 24 Roman Teterin 2016-01-14 21:05:42 UTC
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
Comment 25 Thomas Lübking 2016-01-14 21:14:46 UTC
"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?
Comment 26 Roman Teterin 2016-01-14 21:46:36 UTC
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).
Comment 27 Thomas Lübking 2016-01-14 21:49:46 UTC
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)
Comment 28 Roman Teterin 2016-01-14 22:03:45 UTC
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.
Comment 29 Roman Teterin 2016-01-14 22:12:23 UTC
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.
Comment 30 Thomas Lübking 2016-01-14 23:20:47 UTC
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 ...)
Comment 31 Roman Teterin 2016-01-15 05:43:24 UTC
Yes, when "Accept focus" is set to "force", the window does receive focus. But, just as you said, I'm unable to type anything.
Comment 32 Thomas Lübking 2016-01-15 11:26:32 UTC
*Sigh*
https://git.reviewboard.kde.org/r/126753/

For the records, oracle or open jdk?
Comment 33 Ali Lotfi 2016-01-15 20:22:30 UTC
(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
Comment 34 Thomas Lübking 2016-01-15 21:00:49 UTC
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
Comment 35 Roman Teterin 2016-01-15 21:12:40 UTC
I have OpenJDK.

The patch works, thank you.
Comment 36 Tobiáš Potoček 2016-01-27 14:31:09 UTC
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.
Comment 37 Thomas Lübking 2016-01-27 14:51:16 UTC
5.6.0 - despite the impact is very likely limited to java, it's indeed "wrong" and open for regressions => next minor release
Comment 38 EssL 2016-04-13 17:41:43 UTC
5.6.1 - it's still there...
Comment 39 Robert Charbonneau 2016-04-13 18:09:04 UTC
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.)
Comment 40 Ali Akbar 2021-02-20 21:43:42 UTC
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 .
Comment 41 Dmitry Batrak 2022-05-19 11:25:39 UTC
Created attachment 148992 [details]
Native reproducer
Comment 42 Dmitry Batrak 2022-05-19 11:26:10 UTC
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.
Comment 43 Roland Pallai 2023-01-20 09:11:39 UTC
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.
Comment 44 Roland Pallai 2023-01-20 15:31:01 UTC
@Dmitry Batrak: FYI https://invent.kde.org/plasma/kwin/-/merge_requests/3465