Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Trivial sample app that triggers a keyboard focus bug w/ JDK 1.7 and X11

branch: master

Fetching latest commit…

Octocat-spinner-32-eaf2f5

Cannot retrieve the latest commit at this time

Octocat-spinner-32 data
Octocat-spinner-32 src
Octocat-spinner-32 README
Octocat-spinner-32 pom.xml
README
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

Update
======

Turns out this problem has been identified:

  http://bugs.sun.com/view_bug.do?bug_id=6798064

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

Data
====

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.

Observations
============

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
ICONIFIED after OPENED:

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.
Something went wrong with that request. Please try again.