JDK-5031359 : JavaScript to Applet calls to get DOM objects hangs Netscape
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2004-04-14
  • Updated: 2004-05-18
  • Resolved: 2004-05-18
Related Reports
Duplicate :  
JDK-5048672 - REGRESSION: Message dispatching introduced by #4838960 has severe problems
Relates :  
JDK-4837333 - No return from JavaScript when accessing an applet in loading step
Description
ISV/Customer with a webtop built on Win32/Internet Explorer but uses 
Java Applets and the JavaScript/LiveScript connector to I.E. and the 
Microsoft JVM.

With Sun's JRE 1.4.x plugin and Microsoft VM, IE6 is able
to parse the JavaScript code, load the applet, and then
call the applet methods as needed to pop a new browser
frame, then inside the browser, display a small embedded
canvas panel with some text inside.

However, with Netscape 7.1 and Sun's JRE plugin, the browser
simply hangs and the cursor blocks with the watch-icon, but
no new popup window appears and no embedded canvas panel with
text.

In fact, the browser hangs and I must use the task manager
to force-kill the Netscp.exe process.

In further testing, using the JDK1.5 Beta 1 plugin, we see regression.
IE6 with JRE 1.5Beta1 plugin exhibits the same hang as for Netscape 7.1
Reverting back to MS VM and IE6 again works.

The hang can be reproduced on Mozilla 1.4 - 1.6 and Netscape 7.0, Netscape 7.1 on Linux Redhat 8, 9, and Fedora Core 1 using the Sun JRE plug-in in 1.4.x.
The hang also occurs on Solaris/SPARC Netscape 7 with JRE 1.5B1 plugin.
Comments
WORK AROUND No workarounds have been found as of yet for the type of loading and access to DOM properties as ISV wants.
11-06-2004
SUGGESTED FIX No suggested fix, although a regression in compatibility between 1.4.2_03 plugin and 1.5 Beta 1 plugin have been observed with MSIE6. The latter does not work. However the former does work with MSIE6. So there appears to be some differences in plugins. In addition, none of our JVM plugins work with Netscape or Mozilla, so the complete fix may require modifications to both browser and plugin.
11-06-2004
EVALUATION The testcase uses onload handler to call into java code. Before 1.5, Mozilla/Netscape 7 won't work due to some bug in plug-in side. So for JRE 1.4.x, the onload handler will do nothing. In 1.5, the onload handler should work fine. However, in this case, insertAdjacentHtml is not a standard script method. It is only supported by Microsoft IE. So Mozilla will simply do nothing and you should be able to see some exception thrown in Java console. More investigation is going on for regression in IE. ###@###.### 2004-04-14 Here is some preliminary investigation result for IE hang issue. When Java callbacks to Javascript, CJSObject.InvokeStub gets called and we use PostMessage to post the Javascript request to the main thread's (browser thread) message queue and at same time, we wait for the result to get back. The browser sits in a message loop to get all the messages (See CJavaAdapter.WaitForJS method, PeekMessage). Based on the MSDN documentation,using PeekMessage call, the system delivers pending messages that were sent to windows owned by the calling thread using the SendMessage, SendMessageCallback, SendMessageTimeout, or SendNotifyMessage function. The system may also diliver the internal events. So Posted Message may get processed. Based on the testing result, the Posted Javascript request message will be processed if we minimize IE and then maximize it. However, it is not guaranteed. I changed the PostMessage call to SendMessage and everything works fine. Looks like we need to take a look at why we used PostMessage instead of SendMessage to post the javascript request. (Based on the comment of CJSObject.InvokeStub, use SendMessage may cause deadlock..). Or do we have a better way to avoid the deadlock mentioned in the comments. ###@###.### 2004-04-16 Here is the result of my investigation. During Javascript calls to Java, IE plugin code forks another thread to do the JS to Java processing while using a message loop to wait for the result and in the meantime pumping all the messages we think is important. Here is the code snippet in JavaAdapter.cpp: while( PeekMessage(&msg, hWndActive, 0, 0, PM_NOREMOVE)) { if( msg.hwnd == hWndParent || msg.hwnd == pJA->m_hWnd || msg.message == WM_PAINT || msg.message == WM_TIMER ) { PeekMessage(&msg, msg.hwnd, msg.message, msg.message, PM_REMOVE); TranslateMessage(&msg); DispatchMessage(&msg); } ..... Basically we selectively pump messages, the side effect of doing this is we may end up leaving some messages in the IE's task message queue and PeekMessage will spin in the infinite loop because we use PM_NOREMOVE. So the proposed fix is to pump all the user defined messages (WM_USER +) for all the child windows of the current active window (including the active window itself) in addition to the current messages we selected to pump. ###@###.### 2004-04-29
29-04-2004