Trivial sample app that triggers a keyboard focus bug w/ JDK 1.7 and X11
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Maximally trivial Swing app with a JTextField, which triggers a
keyboard focus issue with JDK 1.7 on X11. Run with:

  mvn compile && mvn exec:java


Turns out this problem has been identified:

With a JDK build without the realNativeFocusedWindow check behavior is
back to what one expects from JDK 1.6.


data/xev-stumpwm-focustoggle.log contains the output of 'xev' for a session in which:

  (1) xev is started, in focus.
  (2) i switch focus away
  (3) and back
  (4) and close the window

data/xev-metacity-focustoggle.log contains similar for metacity (plus mouse events).

To be clear, this is for the xev Window. I don't know of a tool or
method to obtain the equivalent protocol capture for another client.


With openjdk6 and openjdk7 both I see activated and open on initial
start (not necessarily in order):

java.awt.event.WindowEvent[WINDOW_ACTIVATED,opposite=null,oldState=0,newState=0] on frame0
java.awt.event.WindowEvent[WINDOW_OPENED,opposite=null,oldState=0,newState=0] on frame0

In both cases, switching away produces a DEACTIVATED:

java.awt.event.WindowEvent[WINDOW_DEACTIVATED,opposite=null,oldState=0,newState=0] on frame0

However, in both cases, switching back does not generate an
ACTIVATED. In both cases I must take additional action to make the
window activated:

java.awt.event.WindowEvent[WINDOW_ACTIVATED,opposite=null,oldState=0,newState=0] on frame0

With openjdk6, it is sufficient to click in the window. With openjdk7
I must keep the focus on another window in the same workspace, but
click this app's window with the *mouse*.

Another difference is that with openjdk6 on start-up I get an

java.awt.event.WindowEvent[WINDOW_ICONIFIED,opposite=null,oldState=0,newState=0] on frame0

Focus lost/gained

With both OpenJDK 6 and 7 (in stumpwm), switching between two windows
produce no FOCUS_GAINED events ever. The only time I saw a
FOCUS_GAINED was on initial start-up of the application. FOCUS_LOST is
dispatched when I switch away, but there is no FOCUS_GAINED when I
switch back.

Clicking the mouse also does not generate FOCUS_GAINED. Hypothesis:
FOCUS_GAINED is simply broken in both cases, but for whatever reason
it happens to be the case that in OpenJDK 6 the mouse clicks end up
triggering caret activation in spite of no FOCUS_GAINED event being
seen (might this even be a bug? I don't know what correct behavior is
with respect to focus).

Next up - figure out why FOCUS_GAINED is not dispatched.

Ok, adding some System.out.println()'s to
sun.awt.X11.XWindowPeer.handleFocusEvent() indicates that focus events
are not even reaching that point.