JDK-4838960 : Javascript event handlers becoming asynchronous
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.1,1.4.1_04,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2003-03-27
  • Updated: 2004-07-07
  • Resolved: 2003-09-25
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
1.4.1_07 07Fixed 1.4.2_04Fixed
Related Reports
Duplicate :  
Description

Name: gm110360			Date: 03/27/2003


FULL PRODUCT VERSION :
Plug-in Java(TM): Version 1.4.0_02
Utilisation de la version JRE 1.4.0_02 Java HotSpot(TM) Client VM

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Internet Explorer 5.50.4807.2300

A DESCRIPTION OF THE PROBLEM :
Calling an applet's method inside a javascript event handler
makes this handler asynchronous: other event handlers are
called before the first handler has finished his work.
Some events are even lost, their event handler being never
called.

The problem occurs when using recent versions of the plug-in
(for instance 1.3.1_04 or 1.4.0_02 or 1.4.1) and Internet
Explorer 5.5 or 6.0.

It works as expected with IE and an older plug-in (1.3.1) or
with Mozilla 1.1 and any plug-in.

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the following applet
-------------------------------
public class BugJRE extends javax.swing.JApplet{
    public void wait2s(){
  int i=0;
  long time = System.currentTimeMillis();
  while( (time + 2000) > System.currentTimeMillis() ){
   i = i + 1;
  }
    }
}
-------------------------------

2. Save the following HTML page
-------------------------------
<html>
<script language="javascript">
function callJavaOnChange(){
 var t = document.getElementById("debug");
 var JsTime1 = new String(new Date().getTime());
 JsTime1 = JsTime1.substring(JsTime1.length-5);
 t.value = t.value + "\nBegin event("+JsTime1+") onChange";
 document.javaApplet.wait2s();
 t.value = t.value + "\nEnd event("+JsTime1+") onChange";
}
function callJavaOnMouseUp(){
 var t = document.getElementById("debug");
 var JsTime2 = new String(new Date().getTime());
 JsTime2 = JsTime2.substring(JsTime2.length-5);
 t.value = t.value + "\nBegin event("+JsTime2+") onMouseUp";
 document.javaApplet.wait2s();
 t.value = t.value + "\nEnd event("+JsTime2+") onMouseUp";
}
</script>
<body>

<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
width="500"
height="50" align="baseline"

codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Vers
ion=1,3,0,0"
    name="javaApplet">
<param name="code" value="BugJRE.class">
<param name="type"
value="application/x-java-applet;version=1.3">
<param name="MAYSCRIPT" value="true">
</object>

<br/>
<select size="5" onchange="callJavaOnChange();"
onmouseup="callJavaOnMouseUp();">
 <option value="option1" selected>option1</option>
 <option value="option2">option2</option>
 <option value="option3">option3</option>
 <option value="option4">option4</option>
 <option value="option5">option5</option>
</select>
<br/>
<textarea id="debug" rows="20" cols="50"></textarea>
</body>
</html>
-------------------------------

3. Launch Internet Explorer with a recent version of the
plug-in (1.4.0_02), and view the page described in step 2.

4. Put the mouse cursor over option2, click, *do not wait*,
move the cursor over option3, click.

5. After a few seconds with the CPU at 100%, a log of which
event handlers where called will appear in the textarea.


EXPECTED VERSUS ACTUAL BEHAVIOR :
The expected log should be something like this:
Begin event(63014) onMouseUp
End event(63014) onMouseUp
Begin event(65016) onChange
End event(65016) onChange
Begin event(67039) onMouseUp
End event(67039) onMouseUp
Begin event(69042) onChange
End event(69042) onChange

This output means that handlers are called in the same order
as the events are generated:
1st: the onMouseUp for option2
2nd: the onChange for option2
3rd: the onMouseUp for option3
4th: the onChange for option3

The actual log is:
Begin event(31923) onMouseUp
Begin event(32433) onMouseUp
End event(32433) onMouseUp
Begin event(34506) onChange
End event(34506) onChange
End event(31923) onMouseUp

This means that both handlers for the 2 mouseUp run in
parallel, while the event handler for onChange is called
only once instead of twice.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
Use an older plug-in or Mozilla 1.1 (replacing tag <object>
by <applet>)
(Review ID: 178721) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_07 1.4.2_04 generic tiger FIXED IN: 1.4.1_07 1.4.2_04 tiger INTEGRATED IN: 1.4.1_07 1.4.2_04 tiger tiger-b22 VERIFIED IN: 1.4.1_07 1.4.2_04
08-07-2004

EVALUATION Too late for mantis ###@###.### 2003-03-31 This bug is a side effect of fix for bug #4516042. Pumping messages while JavaScript->Java call is being executed is causing this problem ###@###.### 2003-05-13 Further investigation has revealed that in order to have this bug fixed along with #4516042, it is necessary to pump messages for the control window and its parent. Also WM_PAINT and WM_TIMER needs to be pumped for all the children windows of IE frame. ###@###.### 2003-08-11 ---------------------------------------------- ###@###.### 2004-07-07 A new escalation was raised on this issue (see the comments section) -- 1. I tried the fix in IExplorerEmbeddedFrame::setBean(), changing PluginAWTUtil.invokeAndWait() to invokeLater(). Also I increased the refresh interval in the testcase(ManyFrames.html) from 1000ms to 5000ms. This makes the hang go away for a long duration. After a longer duration IE does freeze intermittently, but it tends to come out of it. Looking at the stack trace at freeze time shows the main thread in WPlatformService_waitEvent() at MsgWaitForMultipleObjects(1, &waitingEvent, FALSE, INFINITE, QS_ALLINPUT); 2. But the above fix with refresh interval in the testcase(ManyFrames.html) at 1000ms or 2000ms delays the hang for a lesser time than the 1st case. When hang happens the main thread is in WComponentPeer::pShow() waiting on SendMessage(). At the same time it also holds a lock of type AwtTreeLock, and some other threads(Awt-EventQueue1) are not making progress due to waiting to lock the same AwtTreeLock object. ------------------------------------------------------
08-07-2004