JDK-6200345 : PIT:Button on the parent frame loses focus when clicking a non-focusable comp on the child window
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-11-25
  • Updated: 2011-01-19
  • Resolved: 2004-12-07
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
6Resolved
Related Reports
Duplicate :  
JDK-6200789 - PIT: requestFocusInWindow transfers focus to a component in a frame which is not having focus
Relates :  
JDK-5065001 - awt TextArea crashes HotSpot on winXP when frame is closed
Description
I have a Frame with few components in it. I have created a child window with a multi-selection list added to it. When I show the frame as well as window on the screen, the button on the parent frame is having the focus. Move the mouse over the list on the parent frame and move the mouse wheel. Check whether mouse wheel events are triggered on the console. Move the mouse over the list on the child window. Move the mouse wheel. Check whether mouse wheel events are triggered. Now click on one of the items in the list placed on the child window (BOTH THE LISTS ARE NON-FOCUSABLE). You will notice that the button on the parent frame loses focus. Also mouse wheel events are no longer triggered for any of the lists shown. This is incorrect. Clicking a non-focusable list on the child window should not remove focus from the button.

This is reproducible only on Win32. This is reproducible only on the following PIT build:
java version "awt.pit-jcg-win-03-2004-11-23-Tue-int.mustang"
Java(TM) 2 Runtime Environment, Standard Edition (build awt.pit-jcg-win-03-2004-11-23-Tue-int.mustang)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b13, mixed mode)

Not reproducible on Solaris / Linux with XToolkit.

Run the attached test on Win32. You would see a frame and a child window. Make sure the button has the focus. Without clicking anything, keep the mouse pointers inside the lists and check whether mouse wheel events are triggered. Now keeping the focus on the button, click the non-focusable list on the child window. If button loses focus, then the bug is reproduced. After this focus transfer, mouse wheel events are no longer triggered for the lists.
Comments
EVALUATION I could see similar problem on Solaris with CDE (work remotely). I just run the attached test and click on Choice in child Window. This leads to state when the Button lose focus. I've reproduced it with Mustang b12. ###@###.### 2004-11-25 10:42:18 GMT Reproduced on Windows2000 with pit-build. Might be related to 5065001 due to moving some Components' methods on Toolkit thread. I've unpatched awt_List.cpp and got a crash with attached test. After you click on List in Window, FocusOwner equals null. ###@###.### 2004-11-25 14:03:25 GMT It's reproducible from time to time (as well as other PIT fails: 6200374, 6200807, 6200795, 6200789). I removed last changes from awt_Component.cpp & awt_Component.h (went to previous versions 1.358 & 1.176) and build the workspace. Bugs disappeared. These bugs might be a result of a thread race. Working on it. ###@###.### 2004-11-30 12:40:54 GMT In awt_Component.cpp there was a lot of changes. But we turned to be not ready to some of them. Regarding this problem, the way to call requestFocus was changed. Earlier it was called by means of SendMessage directly, no matter what is the current thread. And the current thread was EventDispatch thread. So this call was performed asynchronously. Now it is called correctly, via InvokeFunction on Toolkit thread. It became synchronous that resulted in some native focus messages being generated. We turned to be not ready to process them. Really, I guess we should find a way to skip them in this situation. ###@###.### 2004-11-30 18:42:39 GMT The fix suggested for the bug 6182359 (where messages for non-focusable windows are filtered) also resolves this problem. ###@###.### 2004-12-03 13:47:33 GMT I noticed that the bug 6200789 is also related to this one. And I guess that that is the root of the problem but not the bug 6182359 whose fix resolves the problem in complex. I think closing it as a duplicate would be the simplest choice. ###@###.### 2004-12-07 15:16:07 GMT
25-11-2004