JDK-6533768 : Window is not getting the focus if the parent frame is set to setFocusableWindowState(false)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-03-13
  • Updated: 2011-04-29
Related Reports
Relates :  
JDK-5090326 - REG: Making parent frame non focusable makes all its child windows non focusable
Relates :  
JDK-6566434 - REG: Choice on a non-focusable window responds to keyboard interactions, XToolkit
Relates :  
JDK-6182359 - Non focusable frame prevents any of it's child windows from gaining focus, on XToolkit
Relates :  
JDK-6532781 - default focus is not there on the window when parent frame is iconified.
Description
1. Create a Frame with setFocusableWindowState(false) and make it visible.
2. Create a Window with a button and make it visible.

Expected result: Button inside the Window should have the focus 
                 it should trigger focus gained event.
Actual resulst:  Button inside the Window is not having the focus 
                 and it is not triggering focus gained event

- the focus is not gained even though "isFocusableWindow" returns true for Window
- click on the button in Window still focus is not gained by the button.
- it happens both in Windows as well as in Solaris.
- This defect is there since 1.5.0 but there is a difference in 1.5.0 clicking on button in windows gains the focus and fires the event but this is broken in jdk 1.6.0 between b10 and b25.

Note: This happens only if the parent frame is setFocusableWindowState(false) same thing works fine for a dialog
Comments
EVALUATION The doc snippet above contains a few unclear statements: 1. By transitivity, this prevents the Window or any of its descendants from becoming the focus owner. By descendants it means child components of the Window, not owned Windows of an owner (Frame/Dialog). 2. Non-focusable Windows may still own Windows that are focusable. It means the following hierarchy: Frame/Dialog -> Window(1) -> Window(2). If Window(1) is non-focusable it may still own focusable Window(2) if the Frame/Dialog is also focusable. 3. Every Window which is not a Frame or Dialog, but whose nearest owning Frame or Dialog is showing on the screen, and which has at least one Component in its focus traversal cycle, is also focusable by default. This statement tells nothing about non-focusable owning Frame/Dialog. But in this case the owned Window cannot be focusable and its isFocusableWindow() method should return false. Thus 1st & 2nd points should be corrected and 3rd point should be fixed. From where we can get that the owned Window of non-focusable owner cannot be focusable? It indirectly follows from this statement of the javadoc: --------------------- Window.isActive Returns whether this Window is active. Only a Frame or a Dialog may be active. The native windowing system may denote the active Window or its children with special decorations, such as a highlighted title bar. The active Window is always either the focused Window, or the first Frame or Dialog that is an owner of the focused Window. ---------------------- If the first Frame or Dialog of an owned Window is non-focusable then it cannot be active and then the owned Window itself cannot be focused (otherwise we would loose the active window). So, we also should make this statement clear in the javadoc. The question is: why the test case shows the owned Window unfocused if its isFocusableWindow() returns false? The reason is the following: 1. On Windows The native code contains its own implementation of isFocusableWindow() that checks for the focusability of an owner. 2. On XAWT The Window gets activated through its owned Frame/Dialog. The last can't be activated and so the Window stays unfocused.
14-03-2007
EVALUATION First, I thought the bug should be closed as not a defect. Indeed, see the following section in the AWT Focus specification: ---- To support palette windows and input methods, client code can prevent a Window from becoming the focused Window. By transitivity, this prevents the Window or any of its descendants from becoming the focus owner. Non-focusable Windows may still own Windows that are focusable. By default, every Frame and Dialog is focusable. Every Window which is not a Frame or Dialog, but whose nearest owning Frame or Dialog is showing on the screen, and which has at least one Component in its focus traversal cycle, is also focusable by default. To make a Window non-focusable, use Window.setFocusableWindowState(false). ---- Looks like the current behavior is exactly what described in the specification. However, I have added a couple of println statements into the code and found an interesting thing: win.isFocusable() returns true - right win.isFocusableWindow() returns true - wrong win.getFocusableWindowState() returns true - right So I think we should investigate this issue further.
13-03-2007