JDK-6647406 : Liveconnect issue : reoccurrence of 5077565
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-01-04
  • Updated: 2010-09-08
  • Resolved: 2008-03-17
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
6u10 b12Fixed
Related Reports
Relates :  
JDK-6790710 - IE hangs up when the mouse is clicked outside of IE
Relates :  
JDK-6661271 - Browser hangs caused by SSV dialogs and fix for 6647406
Relates :  
JDK-5077565 - Java Script event handlers issue.
Relates :  
JDK-6681818 - Modal dialogs occasionally not working properly in new plug-in
Relates :  
JDK-6395737 - IE hangs when a modal dialog is active with concurrent window re-focus activities
Description
Please refer to 5077565 for a testcase and the problem description.

The test failed with both new and classic Java Plug-in on XP using IE browser.

The failure with the new Java Plug-in is more severe in the sense that some events are missing. For the classic Java Plug-in, the failure is that the events aren't being handled synchronously. At this point, it's unclear since which release the problem in 5077565 was re-introduced in the classic Java Plug-in.

Suspecting the failure is due to that we're pumping too many windows messages during liveconnect calls.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6647406.0 testcase: http://j2se.east/deployment/www/tests/1.6.0_10/6647406/
17-01-2008
EVALUATION When we make a JavaScript-to-Java call, we need to run a nested message pump (currently on the Windows platform only) in order to allow the browser to repaint while we are waiting for the result to come back from Java. This nested message pump is also used to implement modal dialog blocking of the browser window. We were dispatching too many types of messages in this message pump, causing input events like mouse and keyboard events to be dispatched while a JavaScript-to-Java call was running. This could cause JavaScript-level event handlers to be called recursively, which is incorrect. The fix is to not dispatch any input events in this nested message pump in the normal case. However, this does not work when a Java modal dialog is visible; testing has shown that when a modal dialog is up, and the message hooks are installed which implement the blocking of the browser window, the nested message pump actually must dispatch input events. A boolean parameter was added to the native method for the message pump to toggle its behavior. The existing infrastructure for the modal dialog handling in the new plug-in made this a very simple and localized change. The structure of the message pump was changed to alternate between waiting for the event object for a brief period of time, with no interruptions from Windows messages, and dispatching a bounded number of messages. This was found to be necessary because we are no longer dispatching all Windows events, so using MsgWaitForMultipleObjects was causing the message loop to consume all CPU, apparently preventing the thread which would otherwise signal the event object from running. The wait period and number of messages processed was tuned slightly with the NeuroDNA application, but the specific numbers do not appear to have a large impact on overall responsiveness. Also fixed a small issue in the LiveConnect code to improve the error reporting in the case where null is passed as an argument to a Java method taking a primitive type such as "int".
17-01-2008
SUGGESTED FIX Below suggested fix is for the old (classic) Java Plug-in: ------- JavaAdapter.cpp ------- *** //C/tmp/sccs.001000 Tue Jan 15 19:57:19 2008 --- JavaAdapter.cpp Tue Jan 15 19:57:01 2008 *************** *** 437,454 **** dwRet = MsgWaitForMultipleObjects(1, &hEvent, FALSE, time, QS_ ALLINPUT ); // If there is a message in the queue if (dwRet == WAIT_OBJECT_0 + 1 ) { ! MSG msg; ! while( PeekMessage(&msg, hWndActive, 0, 0, PM_NOREMOVE) ) { // processing WM_PAINT and WM_TIMER messages seems suffi cient // messages may need to consider are WM_NCPAINT, WM_ERAS EBKGND, and focus related ones ! PeekMessage(&msg, msg.hwnd, msg.message, msg.message, PM_REMOVE); ! TranslateMessage(&msg); ! DispatchMessage(&msg); ! if( !(msg.message == WM_PAINT || msg.message == WM_TIMER ) ) { ! // Set focus on the modal window as long as it's active ! if ( ::GetActiveWindow() != modalhWnd ) { ! ::SetFocus(modalhWnd); ! } } // Check if the JS-Java method is done(i.e event is si gnalled) --- 437,458 ---- dwRet = MsgWaitForMultipleObjects(1, &hEvent, FALSE, time, QS_ ALLINPUT ); // If there is a message in the queue if (dwRet == WAIT_OBJECT_0 + 1 ) { ! MSG msg; ! while( PeekMessage(&msg, hWndActive, 0, 0, PM_NOREMOVE) ) { // processing WM_PAINT and WM_TIMER messages seems suffi cient // messages may need to consider are WM_NCPAINT, WM_ERAS EBKGND, and focus related ones ! PeekMessage(&msg, msg.hwnd, msg.message, msg.message, PM _REMOVE); ! if( (msg.message == WM_PAINT) || (msg.message == WM_TIME R) || ! (msg.message == WM_SETFOCUS) || (msg.message == WM_K ILLFOCUS) || ! (msg.message == WM_NCPAINT) || (msg.message == WM_NC ACTIVATE) || ! (msg.message == WM_ACTIVATE) || (msg.message == WM_M OUSEACTIVATE)) { ! TranslateMessage(&msg); ! DispatchMessage(&msg); ! } else { ! // Set focus on the modal window as long as it's ac tive ! if ( ::GetActiveWindow() != modalhWnd ) { ! ::SetFocus(modalhWnd); ! } } // Check if the JS-Java method is done(i.e event is si gnalled) *************** *** 481,491 **** // If there is a message in the queue if (dwRet == WAIT_OBJECT_0 + 1 ) { 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 sign alled) if(WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) { dwRet = WAIT_OBJECT_0; --- 485,493 ---- // If there is a message in the queue if (dwRet == WAIT_OBJECT_0 + 1 ) { MSG msg; ! while( PeekMessage(&msg, NULL, WM_JPI_MIN, WM_JPI_MAX, PM_RE MOVE) ) { ! TranslateMessage(&msg); ! DispatchMessage(&msg); // Check if the JS-Java method is done(i.e event is sign alled) if(WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) { dwRet = WAIT_OBJECT_0;
16-01-2008
EVALUATION For the old (classic) Java Plug-in, the failure was due to the fix for 6395737 and related bugs. We're pumping too many windows messages in CJavaAdapter::WaitForJS(). A possible fix is in the suggested fix section.
16-01-2008
EVALUATION This appears to be the root cause of more severe issues like stack overflow errors being reported by the JavaScript interpreter with real-world applications like that from www.neurodna.com. Raising the priority to P2.
15-01-2008