JDK-6566434 : REG: Choice on a non-focusable window responds to keyboard interactions, XToolkit
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2007-06-06
  • Updated: 2014-10-24
  • Resolved: 2011-05-18
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
7 b17Fixed
Related Reports
Relates :  
JDK-6533768 - Window is not getting the focus if the parent frame is set to setFocusableWindowState(false)
Description
I have a created a Window with an invisible parent frame and I have added a choice to the window. When I make the window visible, window becomes non-focusable due to lack of an active window. Choice is also non-focusable and does not respond to keyboard inputs. But when I click on it, the drop-down that is shown responds to keyboard inputs and I am able to select items using keyboard. This is incorrect. 

This is reproducible only on XToolkit and not on win32. This is not reproducible on JDK6-b36 but reproducible on b40. Hence it is a regression introduced in JDK6 on XToolkit. Same behavior is seen for null-parent window as well.

Run the attached test. Click on the choice. Try navigating through the items using keyboard. If items are selected, bug is reproduced.
Comments
SUGGESTED FIX --- XChoicePeer.java 2007-06-26 18:21:58.000000000 +0400 *************** *** 1029,1035 **** // notify XWindow that this event had been already handled and no need to post it again EventQueue.invokeLater(new Runnable() { public void run() { ! if(target.isFocusable()) { handleJavaKeyEvent((KeyEvent)e); } } --- 1029,1037 ---- // notify XWindow that this event had been already handled and no need to post it again EventQueue.invokeLater(new Runnable() { public void run() { ! if(target.isFocusable() && ! getParentTopLevel().isFocusableWindow()) ! { handleJavaKeyEvent((KeyEvent)e); } }
26-06-2007
EVALUATION Reopen this CR as the behaviour is wrong because unfocusable window shouldn't transfer any kind of events to itself. Choice component remains focusable regardless of the toplevel state so isFocusable() check is not sufficient here. Better way would be to filter prePostEvent() invocation.
19-06-2007
WORK AROUND To prevent user from input the data to the choice, disable it.
15-06-2007
EVALUATION This is a feature of the choice component. There is a CR that requests exactly this ability. I believe the Motif widget behaves in the same way as well.
15-06-2007
EVALUATION I noticed that the Window in the test says that window.isFocusable()==true; But if even I set this property to false the issue you described still reproduces. So going further. The problem seem is in how isFocusable() works. It just return the value stored in particular component rather then scan the whole hierarchy. So in this case our choice is focusable(it returns TRUE for isFocusable()) with no regard to its parent. Say, if add a choice into non-focusable frame we observe the same effect. CC'ing Anton as he helped me with this testcase and could clarify some things from focus area. Actually we also have similar situation with _enabled_ property. See CR4177727. I'm not sure if we are ready to fix this for _focusability_ property. While reading the Focus Spec. I found two things that contradicts with the test's behavior: 1) "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 (and following test from the Spec.) implies that the window with non-visible parent is not focusable. But in the test if I ask window about its state it returns TRUE. 2) "...a Window whose nearest owning Frame or Dialog is not showing could never receive KeyEvents on X11." But some components (that acquire grab) could hear KeyEvents. This doesn't happen with others (in particular, TextField is OK).
15-06-2007
EVALUATION Most probably the problem appears because the choice drop-down list is in a separate X window, which doesn't inherit unfocusability from the choice parent frame.
07-06-2007