JDK-6769607 : PIT : Modal frame hangs for a while for few seconds in 6u12 b01 pit build
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6u12
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-11-10
  • Updated: 2011-01-19
  • Resolved: 2008-12-03
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 JDK 7
6u12 b02Fixed 7Fixed
Related Reports
Relates :  
JDK-6714829 - REGRESSION: Wrong modal dialog activated after child closed, causes freeze
Description
I have a frame which contains a button , when i press the space bar , another frame is displayed as the first frame acts a modal frame for the second. this chain goes on until you stop creating the new window.  When all the frames are visible, i click on each frame from the newly created frame to the first frame. Then for a while the whole set of frame hangs.  

Step to reproduced:-
-----------------------
1) Run testcase in the CR.
2) Keeping on pressing space bar . Once you see 16 frame. stop it.
3) Click each frame from low order to upper order i,e frame 15, frame14 , frame3...frame1.
4) Observe that frame16 focus border is not drawn correctly. at least the upper part. 5) Now press escape key 4 to 5 times. You will see that different frame are not painted correctly or seen above the other. 

I tested this with 6u12 b01 pit build.
Comments
EVALUATION The AWT modal|mouse hooks call ::BringWindowToTop() to place the blocker dialogs at the top of the Z order. It covers the cases when the blocker dialogs are under other native windows and the blocker dialogs should popup over all native windows when the user clicks on the blocked window. ::BringWindowToTop activate the dialogs and so the underlying system generates new WM_ACTIVATE messages, then AWT gets into the hooks again and calls the ::BringWindowToTop() again and so on. Using ::SetWindowPos(...,HWND_TOP,...) with the SWP_NOACTIVATE flag instead of ::BringWindowToTop fixes the problem.
11-11-2008
EVALUATION This is a regression of the fix for 6714829. When the user clicks on any blocked window, AWT activates all blocker windows by calling ::BringWindowToTop on all these windows (refer to the AWT modal hook routine - AwtDialog::ModalFilterProc). If I comment the ::BringWindowToTop call, then the problem goes away. It looks like activating several windows inside the AWT modal hook procedure (WH_CBT hook) is wrong, underlying system generates many WM_WINDOWPOSCHANGING messages and the system goes into infinite loop.
10-11-2008