Bug 343430 - Java app window does not lose focus after single click on a different window
Summary: Java app window does not lose focus after single click on a different window
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/122...
Keywords:
: 343480 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-28 02:20 UTC by Bo
Modified: 2015-02-12 20:35 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.2.1
thomas.luebking: ReviewRequest+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bo 2015-01-28 02:20:08 UTC
For example, I'd have Android Studio (it's an application written in Java) open on my second monitor and Google Chrome on my first monitor. If I'm typing something in AS and if I click on Chrome address bar, I get the blinking cursor in the chrome's address bar, the window will be "focused", but if I type anything, the text that I type will show up in Android Studio. This includes shortcuts as well - pressing Ctrl+F will open the "search" in Android Studio, not the search in Chrome.

This applies to some other applications as well, such as PyCharm or IntelliJ. Truth be told, they're all developed by the same company (but they're all also written in Java).

This happened when I was testing the new plasma a few months back too, but I did not report it.

Reproducible: Always

Steps to Reproduce:
1. Open Android Studio / IntellIJ IDEA / any application written in Java and type some text
2. Click on a different window (e.g. Konsole/Chrome)
3. Start typing text again

Actual Results:  
Window changes focus, but when typing, text still shows up in the old window.

Expected Results:  
Typed text will show up in the focused window.

A workaround for this behavior is to double-click the other window, to kind of "properly" set focus.
Comment 1 Marco Martin 2015-01-28 10:33:07 UTC
i'm not sure is valid (would more blame the application doing funny things) but more in topic with kwin
Comment 2 Martin Flöser 2015-01-28 10:39:55 UTC
sounds like the application is holding a keyboard grab.

Please go to a tty and execute the following command
DISPLAY=:0 xdotool key "XF86LogGrabInfo"

and then look into /var/log/Xorg.0.log and check whether it reports a grab. If there is a grab it will show something like:
[526989.104] (II) Printing all currently active device grabs:
[526989.104] Active grab 0x6200000 (core) on device 'Virtual core keyboard' (3):
[526989.104]       client pid 28477 kwin_x11 --replace
[526989.104]       at 526979802 (from active grab) (device thawed, state 1)
[526989.104]         core event mask 0x3
[526989.104]       owner-events false, kb 1 ptr 1, confine 0, cursor 0x0
Comment 3 Ilari Mäkimattila 2015-01-28 12:23:28 UTC
I'm having the exactly same issue on same platform (Arch Linux 64bit, plasma 5.2) with different java apps (PhpStorm and Arduino IDE). I'm using focus follows mouse and it works just fine, except for java. The active window hilight stays on the java app and every keypress is sent to it. The only way to change focus seems to be alt+tab.

Here's the grab info:
[ 14257.420] (II) Printing all currently active device grabs:
[ 14257.420] (II) End list of active device grabs
Comment 4 Thomas Lübking 2015-01-28 15:49:17 UTC
As there's no grab, it seems the java client re-*setInputFocus() itself.
I could assume sth. incredibly silly like "while (iAmTheActiveWindow()) XSetInputFocus();"

-> What java? Sun, OpenJDK7 or OpenJDK8? (the arch package name will be sufficient)
Comment 5 Ilari Mäkimattila 2015-01-28 15:53:05 UTC
Oracle java. Package jdk-8u31-2 from AUR.
Comment 6 Bo 2015-01-28 18:19:03 UTC
My situation is the same is Ilari's. 

Xorg.0.log lists:

[ 58380.216] (II) Printing all currently active device grabs:
[ 58380.216] (II) End list of active device grabs

I also have the jdk-8u31-2 from AUR installed
Comment 7 Thomas Lübking 2015-01-28 21:44:58 UTC
*** Bug 343480 has been marked as a duplicate of this bug. ***
Comment 8 Thomas Lübking 2015-01-28 21:46:49 UTC
Confirmed with oracle java (forgot sun sold it) and jedit.
Checking why.
Comment 9 Thomas Lübking 2015-01-28 22:12:45 UTC
I think I know the reason (timestamp issue - old timestamp -> java thinks that "this is MYYYYYY focus!!!" ;-)

The jedit testcase is not as reliable as i'd like it to be.

Can anyone try to apply this patch:

diff --git a/client.cpp b/client.cpp
index 12fbd50..f560e15 100644
--- a/client.cpp
+++ b/client.cpp
@@ -1617,6 +1617,7 @@ void Client::takeFocus()
     previous_focus_timestamp = xTime();
     previous_client = this;
 #endif
+    updateXTime();
     if (rules()->checkAcceptFocus(info->input()))
         m_client.focus();
     else
Comment 10 Thomas Lübking 2015-01-28 22:41:22 UTC
Alternative patch that spares a roundtrip

diff --git a/xcbutils.h b/xcbutils.h
index 9a03134..465cb0e 100644
--- a/xcbutils.h
+++ b/xcbutils.h
@@ -1089,7 +1089,7 @@ public:
     void clear();
     void setBackgroundPixmap(xcb_pixmap_t pixmap);
     void defineCursor(xcb_cursor_t cursor);
-    void focus(uint8_t revertTo = XCB_INPUT_FOCUS_POINTER_ROOT, xcb_timestamp_t time = xTime());
+    void focus(uint8_t revertTo = XCB_INPUT_FOCUS_POINTER_ROOT, xcb_timestamp_t time = XCB_TIME_CURRENT_TIME);
     void selectInput(uint32_t events);
     void kill();
     operator xcb_window_t() const;
Comment 11 Thomas Lübking 2015-02-05 20:57:40 UTC
Git commit 2390024f69f82ba074a2292e22cb2b431ca6ec39 by Thomas Lübking.
Committed on 28/01/2015 at 22:41.
Pushed by luebking into branch 'Plasma/5.2'.

use xcb_time_current_time as setinputfocus default
REVIEW: 122298
FIXED-IN: 5.2.1

M  +1    -1    xcbutils.h

http://commits.kde.org/kwin/2390024f69f82ba074a2292e22cb2b431ca6ec39
Comment 12 Thomas Lübking 2015-02-05 20:58:04 UTC
Git commit 96628a698c92eb96bd8563d0de8e2969d9d23320 by Thomas Lübking.
Committed on 28/01/2015 at 22:41.
Pushed by luebking into branch 'master'.

use xcb_time_current_time as setinputfocus default
REVIEW: 122298
FIXED-IN: 5.2.1

M  +1    -1    xcbutils.h

http://commits.kde.org/kwin/96628a698c92eb96bd8563d0de8e2969d9d23320
Comment 13 kde 2015-02-05 20:59:06 UTC
I just wanted to add that I've got almost the same problem, only with Opera 12 which, as far as I know, has got nothing to do with Java.
Double-clicking in the other window also doesn't do the trick, I have to either use Alt+Tab or move the window twice using the title bar.
Comment 14 Thomas Lübking 2015-02-05 21:56:46 UTC
It's not so much about the particular toolkit, but about what the toolkit does on activating a windonw (but the opera hint would have spared me a Oracle JRE installation for testing ;-)