JDK-5090326 : REG: Making parent frame non focusable makes all its child windows non focusable
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version:
    1.4.2,5.0,6,7,8,9,10,11,12,13,14,15,16,17,18 1.4.2,5.0,6,7,8,9,10,11,12,13,14,15,16,17,18
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux,linux_sun
  • CPU: x86
  • Submitted: 2004-08-21
  • Updated: 2022-07-12
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-6533768 - Window is not getting the focus if the parent frame is set to setFocusableWindowState(false)
Description
I am popping up a frame with 2 child windows. The frame is the parent of the first child window and the first child window is the parent of the second window. When the frame's focusable state is set to false, none of the child windows gain focus on XToolkit. The child windows are unusable when parent frame is non focusable. As per the focus specification, a non-focusable parent window can still own focusable child windows. 

This is reproducible on Cinnabar and on Solaris9-CDE when running with XToolkit option. This is not reproducible on Win32 and Sol9 (Motif). This is introduced in some Tiger build between b09 to b32d. That is, this is not reproducible on Tiger-b09 but reproducible on Tiger-b32d. This is not reproducible on any of the previous releases. Hence this is a regression introduced in Tiger.

I have attached a sample test to this bug report. Run it on linux/solaris with XToolkit option. You would see a frame and 2 windows, each having a text area. Try clicking on any of the windows and try typing some text in the given text areas. If no action is taken, the bug is reproduced.
Comments
Test build: JDK11b23(CC-build(http://slc07hab.us.oracle.com/jdk_coverage/builds/11_23/jdk-11-instr_linux-x64_bin.tar.gz )) Platform :ubuntu18.04-x64 ute tool: tonga-4.0.2-rc2.jar Test case:AWT_Focus/Automated/Lw/FocusableWindowsTest/FocusableWindowsTest.html The case failed as the same issue refer to the log:http://sc11152645.us.oracle.com:8080/evergreen/results/11/b23/awt-cc/auto/ubuntu18.04-x64/results-awt-run1/ResultDir/FocusableWindowsTest.html/FocusableWindowsTest.html.log
07-08-2018
On OS X 10.8: AWT_Focus/Automated/AWT/FocusableWindowsTest/FocusableWindowsTest.html
14-11-2012
EVALUATION Indeed, the Focus Spec states that "Non-focusable Windows may still own Windows that are focusable". Actually, non-focusable Frame/Dialog may not own a focusable Window.
16-06-2009
EVALUATION We block native focus from owning Frame regardless of the fact that it owns focusable window. For the child window to receive focus, we must activate owning Frame. Looks like a leak in a spec - if we then hide the child window, Frame will remain active while non-focusable. However, Motif behaves this way and we must make XAWT work similar for the sake of backward compatibility. ###@###.### 2004-08-23
23-08-2004