JDK-6268552 : REG: TextArea on a disabled frame responds to keyevents, XToolkit
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2005-05-11
  • Updated: 2007-10-16
  • Resolved: 2006-03-20
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 b77Fixed
Related Reports
Relates :  
JDK-6181163 - REGRESSION: Disabled textfield responds to keyevents visually on win32
Relates :  
JDK-5042122 - REGRESSION: TextField.setEnabled(false) does not grey out text.
Relates :  
JDK-6176875 - XAWT: disabling lightweight container disabled heavyweight children
Relates :  
JDK-6181270 - REGRESSION: Textarea responds to keyevents visually when it is disabled, on win32
Description
I have added a textarea and a button to a frame and the frame is disabled. I expect the components in the frame to ignore keyboard and mouse events. But when I pressing some keys while clicking inside the textarea, I could see the text whatever I typed on the keyboard. This is incorrect. The textarea should never get those keyevents. 

This is reproducible on Mustang-b35 and not reproducible on Tiger-FCS, on XToolkit - SolarisSparc10-JDS. Hence it is a regression introduced in Mustang.

I have attached a sample test. Execute the sample test. Keep clicking inside the textarea repeatedly (on the text shown) and press some keys at the same time. You would see some text appearing on the textarea.
###@###.### 2005-05-11 12:47:57 GMT
Comments
EVALUATION See 6176875 which fixes correct enabling/disabling of XAWT component peers depending on heaviweight ancestors. setEnabled call happens in postInit which is invoked from XBaseWindow's constructor. 5042122 fix interferes with this mechanism, calling setEnabled() again from XTextField/XTextArea constructor regardless of the state of heavyweight ancestors. This call is unnecessary and should be removed.
25-01-2006
EVALUATION Introduced after JDK6.0b32. I could see it with b33 and b35 local workspaces. Looks like a regression of setEnabled() fix for disabled text components. ###@###.### 2005-05-12 09:25:12 GMT Possibly related to 6181163 and 6181270. Should try fixing this on shared code level. ###@###.### 2005-07-10 17:48:24 GMT
12-05-2005