JDK-6395737 : IE hangs when a modal dialog is active with concurrent window re-focus activities
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2_10,1.4.2_14
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows,windows_xp
  • CPU: x86
  • Submitted: 2006-03-08
  • Updated: 2010-04-04
  • Resolved: 2008-04-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.
Other Other JDK 6 JDK 7
1.4.2_17-revFixed 1.4.2_18 b05Fixed 6u4Fixed 7Fixed
Related Reports
Duplicate :  
JDK-6498792 - IE hangs when you open another IE while modal dialog is up
Relates :  
JDK-6647406 - Liveconnect issue : reoccurrence of 5077565
Relates :  
JDK-6247308 - REGRESSION: Particular Applets won't work in IE anymore when using the latest Java plugin
Relates :  
JDK-6523707 - IE browser thread dead after modal dialog created from liveconnect in another window
Description
his is a from a customer escalated case, esc# 1-14567918, case# 64879233.

To reproduce,
1. load the attached html "testAppletSimple.htm", this will bring up the
   applet which basically draw a box
2. close the browser by clicking the "x" of the browser window (or click browser's
   back button. This is better since no need to quit browser), this will
   trigger the modal dialog window
3. Now that the modal dialog window is up, click another window to activate
   (eg a command prompt window)
4. go back to the browser window by clicking on the window frame.
5. At this time, the modal dialog can still get focus and clickable.
6. Click the other application window again. Then come back click the browser window.
7. Now the modal dialog can not get focus and not responsive to click. In 5.0u7, try     to click button in the modal dialog. It does not seem to respond at first. 2-3        seconds later, the dialog goes away and the browser closes window (or back to         previous page if you click back button).


Also attached is a java stack trace at the time of the hang.

Cu has reproduced the problem on JDK 1.4.2_06 and 1.4.2_10.
I have seen this problem on 1.4.2_11 and 1.5.0_04 as well.
Comments
EVALUATION Fixed in 1.4.2_17-rev-b10
03-04-2008
EVALUATION In WaitForJS in JavaAdapter.cpp this is what I had modified as a fix for the issue. We saw messages with id 0x8002 and hence added a separate case to handle it. PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE) ; if( msg.message == 0x8002) { PeekMessage(&msg, msg.hwnd, msg.message, msg.message, PM_REMOVE) ; TranslateMessage(&msg); DispatchMessage(&msg); } while( PeekMessage(&msg, NULL, WM_JPI_MIN, WM_JPI_MAX, PM_REMOVE)) { TranslateMessage(&msg); DispatchMessage(&msg); // Check if the JS-Java method is done(i.e event is signalled) if(WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) { dwRet = WAIT_OBJECT_0; break; } } The customer has come back with 2 issues. 1. This fix does solve the problem but only partially. If you repeat the steps multiple times, of going back and forth, you can see the hang happen. I can reproduce it here at my end. I looked into the messages through printing, and realize that the message not being processed is > 0xC000 ( the value changes as this is a runtime #). Messages in the system > 0xC000 are string messages sent for message registered by application using RegisterWindowMessage. I looked in the plugin code and we use RegisterWindowMessage only in one place in IEBrowserEventListener.cpp. The rest of the functions in this class are not being invoked except this message getting registered. Hence, it doesn't make sense that this message is being sent. This could also be IE internal message as well, but typically MS is careful and dont range their internal messages in this range. If I only add code to check for this message and process it , it also sends some more regualr windows messages. Since our popup dialog is a modeless dialog in implementation and we force it to behave like a modal dialog to users. I tried the message loop to handle the messages as suggested for modeless dialog. This resolves the issue. Since in our plugin code this is the only active message loop at this time, if we dont handle all messages some or the other message id is not covered and gets pending and it loops forever. Hence, I modified the code as follows: MSG msg; while( PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { if (!IsDialogMessage(pJA->m_hWnd, &msg)) { TranslateMessage(&msg); DispatchMessage(&msg); } // Check if the JS-Java method is done(i.e event is signalled) if(WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) { dwRet = WAIT_OBJECT_0; break; } } This fixes the issue. It also fixes the other issue they have below. 2. The customer slightly modified the process of reproducing the bug as follows: Steps to reproduce the new one: 1. Click on "testAppletSimple.htm". This should bring up the Applet in IE browser. 2. Close the applet window using "X" of the IE browser. This should display a modal dialog. 3. While the modal dialog is up, open a new session of IE 4. Go back to the applet window (not the modal dialog), click on the browser anywhere. 5. You will see that the CPU utilization is up to 100% and applet IE window hangs. Once you start a new instance of IE , or Outlook or any complex application, it hangs the process. With the above modification of letting IsDialogMessage handle the dialog messages and use all other messages through translate and diaspatch, this issue is also resolved too.
15-02-2007
EVALUATION I did some investigation and came to conclude that the message loop in jpicom32.dll in the CJavaAdapter::WaitForJS function is not handling the application message 0x8002. The message 0x8002 is sent when the focus problem is seen. Hence, dispatching this message to the correct window fixes the problem. Please also see Calvin's comments in bug id 6247308.
27-11-2006
EVALUATION It is reproducible in Mustang. I tried the latest build of Mustang and still see it. The trick to reproducing is to switch to another application and click on the browser window of the test case modal dialog instead of clicking on the modal dialog itself. Switch task more than once, repeating the process also reproduces the bug more easily. I am working on the issue in 1.4.2 , currently investigating the modality listener section in j2se and plugin.
18-09-2006
EVALUATION This is not reproducible in JRE 6. We've changed the modality implementation so that browser window cannot be activated (regain focus) untill the modal dialog is dismissed. Tested with b98.
12-09-2006