United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4452384 Action to unfocusable window should not generate any focus event
JDK-4452384 : Action to unfocusable window should not generate any focus event

Details
Type:
Bug
Submit Date:
2001-04-30
Status:
Closed
Updated Date:
2004-09-16
Project Name:
JDK
Resolved Date:
2002-09-06
Component:
client-libs
OS:
generic,windows_2000
Sub-Component:
java.awt
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.1_03 (03)

Related Reports
Backport:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
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);
        frame.add(button1);

        window = new Window(frame);
        window.setSize(100, 100);
        window.setFocusableWindowState(false);
        window.add(button2);
        frame.setVisible(true);
        window.setVisible(true);

    }

}

class MyFocusListener implements FocusListener {

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

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

}

======================================================================

                                    

Comments
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
                                     
2002-08-21
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


                                     
2004-09-17



Hardware and Software, Engineered to Work Together