United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6798064 Keyboard focus is lost in Swing application after switching to window
JDK-6798064 : Keyboard focus is lost in Swing application after switching to window

Details
Type:
Bug
Submit Date:
2009-01-27
Status:
Closed
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2010-11-26
Component:
client-libs
OS:
linux
Sub-Component:
java.awt
CPU:
x86
Priority:
P4
Resolution:
Not an Issue
Affected Versions:
7
Fixed Versions:

Related Reports

Sub Tasks

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

A problem with the specific window manager, reassigned to AWT
                                     
2009-02-04
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

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



Hardware and Software, Engineered to Work Together