JDK-5044469 : REG: Disabled component gains focus and receives keyevents on win32
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1,1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-05-10
  • Updated: 2005-12-01
  • Resolved: 2005-10-22
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 6
6 b58Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
I am popping up a frame with 3 buttons. On clicking the first button, all the 3 buttons located at the southern region of the frame will be disabled. When running this application on win_xp, when I click the first button, all the 3 buttons are getting disabled but focus is shifted to the second buton which is in disabled state. When I press the space bar, this disabled button received the keyevent and triggers the action event. This is incorrect. A disabled component should not gain focus and should not respond to any of the key or mouse events. 

This is not reproducible on Solaris-Sparc9 (CDE). This is reproducible since JDK1.4.2-fcs and is working fine on the previous releases. This is reproducible on Tiger-beta2-b50. 

I have attached a sample test. Execute the sample test. Click the 'Disable' button. Make sure all the 3 buttons are disabled. Press the space bar. When the second button 'Click Me' triggers action event, the bug is reproduced.

Comments
SUGGESTED FIX See http://sa.sfbay.sun.com/projects/awt_data/mustang/5044469.1/
28-02-2005

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang FIXED IN: mustang
17-09-2004

EVALUATION It is ok for the disabled component to receive focus, usually it happens on manual request or if there is no other place to put the focus on. It behaves this way so that you can temporarely disable the component(or a set of components) and be able to continue keyboard navigation after the components are reenabled. This doesn't contradict with any specification, and complies with platform behaviors. However, it is not good that key press is dispatched and disabled button is pressed - this contradicts with specification. On motif, disable components can't keep focus. On XAWT, button don't get pressed. But on Windows disabled button has focus and can be pressed. This should be fixed. We already have some fix in our code, it prevents dispatching of key events to a disabled component. Somehow this fix doesn't work, I suspect this happens because we dispatch the key event in this case into the native layer that generates WM_ACTION regardless of enabled state of the component, and we dispatch this WM_ACTION. ###@###.### 2004-05-10 Name: adR10249 Date: 05/14/2004 Appeared between 1.4.2 b01 and b07 as the result of redesigning of action's handling by Button and this is a regression of 4531849. Simpliest solution is to check for enabling|disabling component before invoke NotifyListeners(). ###@###.### 14-May-2004 ====================================================================== Name: adR10249 Date: 05/20/2004 Not a Tiger regression; appeared in 1.4.2. ###@###.### 20-May-2004 ======================================================================
17-09-2004