JDK-4452384 : Action to unfocusable window should not generate any focus event
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2001-04-30
  • Updated: 2004-09-16
  • Resolved: 2002-09-06
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.
1.4.1_03 03Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
If a Window is set to unfocusable by Window.setFocusableWindow(false), any action, e.g., clicking on the window to try to give it focus, should not generate any focus event by that action, and the focus should remain in the same component that has focus previously.

One of the requesters of setFocusableWindow is the Input Method Framework, and due to this problem, IMF needs to add some workaround.

naoto.sato@Eng 2001-04-30

Name: rpR10076			Date: 08/02/2001

The following testcase can be used to demonstrate the problem:
import java.awt.*;
import java.awt.event.*;

public class Test {

    public static void main(String[] args) {
        Frame frame;
        Window window;
        Button button1;
        Button button2;

        frame = new Frame("test");
        button1 = new Button("button1");
        button1.addFocusListener(new MyFocusListener());
        button2 = new Button("button2");
        frame.setSize(200, 200);
        frame.setLocation(200, 200);

        window = new Window(frame);
        window.setSize(100, 100);



class MyFocusListener implements FocusListener {

    public void focusGained(FocusEvent evt) {
        System.out.println("Focus gained");

    public void focusLost(FocusEvent evt) {
        System.out.println("Focus lost");



CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_03 mantis FIXED IN: 1.4.1_03 mantis INTEGRATED IN: 1.4.1_03 mantis VERIFIED IN: 1.4.1_03

EVALUATION Name: rpR10076 Date: 08/02/2001 ###@###.### I have updated the description with a test case. It has a frame (with button1) and a non-focusable window (with button2). The focusability of a window, by the way, is now changed by setFocusableWindowState(boolean) method. When the test starts, button1 has focus. You can check this by pressing space bar. Button1 has focus listener, and it shows that if you click on button2, button1 loses focus and then gains it back. Moreover, if you double click on button2, button1 may lose focus without regaining it. All these experiments were made with beta b73, on winNT, and the bug looks still reproducible with that configuration. ====================================================================== Name: rpR10076 Date: 11/15/2001 commit to hopper and tiger ====================================================================== We spent some time investigating this, and it seems that it will take a significant amount of work. We can begin working on it, but our focus engineers thought this would be a risky project for Hopper. I'd like to defer it to mantis if we can. ###@###.### 2002-03-22 Name: dmR10075 Date: 08/21/2002 Current implementation tries to achieve non-focusability in gentle way - if on native level non-focusable window or component became focus owner then it starts "focus rejection" process which returns focus to some focusable window/components. However, this doesn't work well sometimes and on Solaris it is even impossible sometimes. So, it was decided to rewrite this implementation by using the means of native system to make some window truly non-focusable. On Windows, it is WM_MOUSEACTIVATE message in response to which we can return MA_NOACTIVATE and window will not be activated. We also need to take care of the mouse event caused activation because window controls make themself focus owners on mouse events and thus activate window. We also should not activate windows in calls to setVisible, toFront/toBack, setState On Solaris, we can use overrideRedirect for Window as it is guaranteed to make it non-focusable and for other windows we can set XmInput = False, which according to ICCM, should make our windows NoInput windows. ###@###.### 2002-08-21 ====================================================================== Need to see if this also resolves Swing bug 4218084. ###@###.### 2002-08-29