JDK-6798064 : Keyboard focus is lost in Swing application after switching to window
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2009-01-27
  • Updated: 2011-01-19
  • Resolved: 2010-11-26
Description
FULL PRODUCT VERSION :


A DESCRIPTION OF THE PROBLEM :
This is a problem shared between Java >=1.6 and the ion3 window manager.
In combination, a Swing application which has keyboard focus on a field will lose it if you change to other window and return back to the first one. Then, no key works until you click again on any field.

This happens prominently with Netbeans 6.5 (all editors are blocked) but also with a simple program like this one:

--- TypeInSwing.java ----------------------------------------

import javax.swing.JFrame;
import javax.swing.JTextField;

public class TypeInSwing {
  public static void main(String[] args) {
    JFrame frame = new JFrame("HelloWorldSwing");
    final JTextField field = new JTextField("type here");

    frame.getContentPane().add(field);

    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.pack();
    frame.setVisible(true);
  }
}

--------------------------------------------------------------


  To reproduce the bug:
1. Install in GNU/Linux the ion3 window manager (both 20080207-2 from Ubuntu or the latest version, 20090110, works. You can run it without installing via http://modeemi.fi/~tuomov/dl/Ion3.xml
2. Learn to move between tabs with the keyboard. I think the default is Alt+K N for next and Alt+K P for previous.
3. Run some programs so that you have more than one tab.
4. Run that example program with Java 1.6 or 1.7.
5. Click on the text field and type; it works.
6. In ion's tab bar, select another tab (either with mouse or with keyboard).
7. Select the example program's tab again (either with mouse or with keyboard).
8. Try to continue typing, but it doesn't work. The cursor is nowhere. You must click again in the editor.

In my tests I saw:
- another window manager (ex: icewm) doesn't show this problem: the focus isn't lost. This with Java 1.6
- but in ion3, Java 1.4 and Java 1.5 also don't show this problem.
- Affected: Java 1.6.0_06 on Ubuntu, Java 1.6.0_10 on Debian, OpenJDK 1.6.0_0-b11 Debian, Java 1.7.0-ea-b43 Debian.
- Not affected: sun-java5-bin on Debian Etch, gij/libgcj 1.4.2 (4.0.2), 1.5.0_16-b02 on Debian

This may be a regression in Java 1.6 or a bug in ion3.



REPRODUCIBILITY :
This bug can be reproduced always.

Release Regression From : 5.0
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION The problem is still reproducible in latest jdk7 and 6 update builds on xmonad/ion3 WMs. There is a bug submitted against xmonad: http://code.google.com/p/xmonad/issues/detail?id=177 that describes the problem in WM: "Java sets <Globally Active> model for its Frames/Dialogs, and <No Input> model for its Windows. In both of these cases the WM shouldn't call XSetInputFocus by itself. In the former case it should send the WM_TAKE_FOCUS event to the window (when it decides that the toplevel window should get the focus), in the latter case it shouldn't do anything (Java processes all the clicks by itself)." The test attached to the report demonstrates the problem: "The correct behaviour of this program in the WM is to print the message "event on frame %i: WM_TAKE_FOCUS" (where %i is the number of frame, 0 or 1 in this program) whenever the focus is set to its window using the WM (either using keys, or mouse). Incorrect behaviour is when it prints only pairs of the "FocusIn"/"FocusOut" messages." When I run the native test in my environment (xmonad 0.9.1), I'm always seeing that the test prints the "FocusIn"/"FocusOut" messages (without any WM_TAKE_FOCUS) event which is considered improper. So, I'm closing this CR as "Not a defect". In addition to the above, it should be mentioned that in jdk7 the failure becomes more severe. This is how the Java's test behaves: 1-7. same as the CR describes 8. try to continue typing, but it doesn't work. Try click in the editor and continue, it still DOESN'T work. So, user unable to move focus to the editor at all. It's been introduced by the following focus changes (part of 6522725): src/solaris/classes/sun/awt/X11/XDecoratedPeer.java public boolean requestWindowFocus(...) + if (target == realNativeFocusedWindow) { + focusLog.fine("The window is already natively focused."); + return true; + } Obviously, the method will always skip "request focus" when WM automatically sets the input focus itself. I guess this is what happens on xmonad/ion3: when the user moves mouse over a window, the WMs set focus to the window because the focus-follows-mouse policy is enabled by default in the WMs.
2010-11-26

EVALUATION An issue specific to Ion window manager (officially not supported). Not reproducible for me using ubuntu 8.04, GNOME, Metacity window manager, jdk6u7.
2009-02-06

EVALUATION A problem with the specific window manager, reassigned to AWT
2009-02-04