United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4838960 Javascript event handlers becoming asynchronous
JDK-4838960 : Javascript event handlers becoming asynchronous

Details
Type:
Bug
Submit Date:
2003-03-27
Status:
Closed
Updated Date:
2004-07-07
Project Name:
JDK
Resolved Date:
2003-09-25
Component:
deploy
OS:
windows_xp,windows_2000
Sub-Component:
plugin
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.1,1.4.1_04,5.0
Fixed Versions:
1.4.1_07 (07)

Related Reports
Backport:
Backport:
Duplicate:

Sub Tasks

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


------------------------------------------------------
                                     
2004-07-08
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


                                     
2004-07-08



Hardware and Software, Engineered to Work Together