JDK-7147075 : JTextField doesn't get focus or loses focus forever
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2012-02-20
  • Updated: 2014-03-11
  • Resolved: 2013-04-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u40Fixed 8 b87Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_03"
Java(TM) SE Runtime Environment (build 1.7.0_03-b04)
Java HotSpot(TM) Client VM (build 22.1-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux Celsius 3.2.6 #1 SMP Wed Feb 15 12:04:35 CET 2012 i686 Intel(R) Pentium(R) D CPU 3.20GHz GenuineIntel GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
XWindow manager: IceWM. No KDE, Gnome or such.

A DESCRIPTION OF THE PROBLEM :
1. A JTextField created as a child of the main JFrame _never_ gets the focus when the user clicks into it.

2. A JTextField in a dynamically created JDialog loses the focus as soon as the cursor is moved out of the parent JFrame, and _never_ gets it back.

No such problems on Windows XP!

REGRESSION.  Last worked in version 6u29

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Start attached test program.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Text field should gain focus when clicked into.
ACTUAL -
Text field gets focus once and then loses it forever, or doesn't get it at all.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

// Focus bug

public class Focusbug
    extends JFrame
{
    JDialog dia;

    Focusbug(String titel)
    {
        super(titel);
        setDefaultCloseOperation(EXIT_ON_CLOSE);

        dia = new JDialog(this);
        dia.setBounds(10, 10, 200,70);
        dia.add(new JTextField("One-way focus"));

        JButton start = new JButton("Create dialog");

        start.addActionListener(new ActionListener()
        {
            public void actionPerformed(ActionEvent e)
            {
                dia.setVisible(true);
            }
        });

        add(start, BorderLayout.NORTH);

        JPanel panel = new JPanel();

        panel.add(new JTextField("No focus here"));
        add(panel, BorderLayout.SOUTH);
    }
    
    static public void main(String[] args)
    {
        Focusbug focusbug = new Focusbug("Focusbug");

        focusbug.setBounds(100, 100, 250, 100);
        focusbug.setVisible(true);
    }
}


---------- END SOURCE ----------

Comments
The same problem is described in 8009224. Below I'm duplicating what has been discovered. It's a regression of 6613426 (integrated in jdk7 b27). 6613426 is a workaround for a Metacity issue [1]. Some WMs (which are reported to fail: e16, IceWM, CygwinX) don't strictly follow "Global Active" focus model specification [2], which assumes that a WM doesn't set focus to a window, but only notifies it with WM_TAKE_FOCUS client message (for example, when the window is clicked). But the focus log (sun.awt.X11.level=ALL) shows that the frame is natively focused right after it receives WM_TAKE_FOCUS which prevents the frame from normal activation (due to the fix for 6613426). Suggested fix: http://cr.openjdk.java.net/~ant/JDK-7147075/webrev.0 It narrows down the scope of 6613426 to Metacity WM only. [1] https://bugzilla.gnome.org/show_bug.cgi?id=485016 [2] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
10-04-2013

Problem occurs under 64bit version as well rdcesx12129> java -version java version "1.7.0_15" Java(TM) SE Runtime Environment (build 1.7.0_15-b03) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) Cygwin is the same version as used with 32-bit.
25-03-2013

CygwinX environment /install/java7_32bit/jre1.7.0_13/bin/java -version java version "1.7.0_13" Java(TM) SE Runtime Environment (build 1.7.0_13-b20) Java HotSpot(TM) Server VM (build 23.7-b01, mixed mode) Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.13.3.0 OS: CYGWIN_NT-6.1-WOW64 d71059 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.13.3-1 built 2013-03-09
21-03-2013

Also, looks like this issue was raised on the OTN forum maybe a week ago.. https://forums.oracle.com/forums/thread.jspa?threadID=2510532&tstart=0
20-03-2013

This happens with Cygwin-X with any window manager except rootless mode with Motif window manager. It also happens with Xming and they don't provide alternate window managers. All window managers work with Xming and Cygwin-x w/ Java 6
20-03-2013