United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6647406 Liveconnect issue : reoccurrence of 5077565
JDK-6647406 : Liveconnect issue : reoccurrence of 5077565

Details
Type:
Bug
Submit Date:
2008-01-04
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-03-17
Component:
deploy
OS:
windows_xp
Sub-Component:
plugin
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b12)

Related Reports
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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
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.
                                     
2008-01-15
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;
                                     
2008-01-16
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.
                                     
2008-01-16
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".
                                     
2008-01-17
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/
                                     
2008-01-17



Hardware and Software, Engineered to Work Together