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.
|
Java