Java Solaris Communities Sun Store Join SDN My Profile Why Join?
» search tips 
Sun Developer Network
Developers Home > Products & Technologies > Java Technology > Community > Bug Database >
Join SDNWhy Join
 
Bug Database
Bug Detail
Quick Lists
-  Top 25 Bugs
-  Top 25 RFE's
-  Recently Closed Bugs
Printable Page Printable Page


Bug Database
Welcome
 
»  Login
»  Report a Bug
»  FAQs
  Bug Watch List:
» Watch this Bug with its releases
 Bug Votes:
 This bug is Closed.You cannot Vote for it.
Bug ID: 4838960
Votes 33
Synopsis Javascript event handlers becoming asynchronous
Category java_plugin:ocx
Reported Against 1.4.1 , 1.4.1_04 , tiger-beta2
Release Fixed 1.4.1_07, 1.4.2_04(Bug ID:2096886) , 1.5(tiger) (Bug ID:2096887)
State 10-Fix Delivered, Verified, bug
Priority: 4-Low
Related Bugs 4902922
Submit Date 27-MAR-2003
Description 




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 :
 customer  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>

< customer  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">
</ customer >

<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 < customer >
by <applet>)
(Review ID: 178721) 
======================================================================
Work Around 
N/A
Evaluation 
Too late for mantis
  xxxxx@xxxxx   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
  xxxxx@xxxxx   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.
  xxxxx@xxxxx   2003-08-11

----------------------------------------------

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


------------------------------------------------------
Comments
  
  Include a link with my name & email   

Submitted On 10-APR-2003
bertung 
This is a serious problem. It is even very severe on 1.4.1+ 
including 1.4.2 beta. In my application with 1.4.1 the stack of 
IE's javascript engine overflows with methods calls from 
javascript to java.Methods calls never delivered to the plugin. 
I have the same configuration as reporter. IE 5.5 on windows 
2000


Submitted On 10-APR-2003
bertung 
Although it is too late for mantis. It is a critical bug. And you 
have this bug on almost 4 different plugin releases. Malicious 
web sites may crash user's machine with little effort.


Submitted On 11-APR-2003
bertung 
New and even worse sideeffect: For every java method call 
from javascript(it doesnt have to be in a javascript handle)
IE creates a new handle and does not release it. If you open 
the window task manager, then observe the number of 
handles increasing all the time for each mouse click and they 
are never released. It also eats up memory as well.


Submitted On 27-APR-2003
AntrygA 
this bug is very critical to us. as long as
javascript-to-java calls are not really synchronous the only
solution for us is to use the 1.1 plugin. also mozilla based
browser cannot be used.
i can reproduce this behaviour on all win32 based machines!


Submitted On 15-MAY-2003
AntrygA 
The behaviour as it is now is in fact not bad, because it
does not freeze browsers when a javascript calls a java
method which then needs long time to process. With java 1.3
or below it will freeze browsers.

But with the bugfix #4516042 javascript-java is not
synchronized anymore and this results most of the time in a
very bad behaviour of a webablication.

e.g: User clicks on an html button which executes an
javascript-to-java call. The call would need e.g 5 seconds
to be returned. In the same time the user can easly click on
an other button which then executes an other call. If this
call needed data from the first call, it will not have the
data because the first call has not been returned! This
results in most of the time in a complete mess ;-(

can you fix the bug in a way that it will not freeze the
browser.-> browserwindow can be moved and resized but no
html element and/or  javascript functions can be executed
before the result has been returned?


Submitted On 26-JUL-2003
yimasun 
This is a critical issue for us.  Our win XP certification is in 
question since Microsoft VM is no longer distributed so there's 
no fall back.  Rolling back the version of JDK is not an option 
for us as it clashs with other requirements.

This seems to be a serious issue for a lot of people, I don't 
see how sun could afford not to fix this ASAP.


Submitted On 17-AUG-2003
mqsash 
Like many others we are porting all our java / js to Sun JVM 
because Miscrosoft will no longer support Java from 2004. 
This is very elementary problem -- it causes a stack overflow 
by making multiple calls to the applet incase of events like 
timer and mouseover etc. Unless this is fixed nobody can 
move to Suns JVM.


Submitted On 08-SEP-2003
mqsash 
This is fixed in tiger..... From what I read tiger will be out by 
the end of the year... but then isnt there a beta coming 
soon ?


Submitted On 04-OCT-2003
bertung 
This fix must be included in an early relase than the Tiger. We 
are sick of getting stack overflow messages from Sun plugins 
from javascript event handlers. I will never understand why 
Sun killed the deal with Microsoft on their MVM. Microsoft 
Virtual Machine is almost 8 years old and still much more 
stable and faster than your newest plugins.


Submitted On 10-OCT-2003
A_Silicon_Sky 
thats soooo true!
btw why not releasing an every day compilation? as so many
open source project are doing! we could have tested this fix
for almost 3 months!


Submitted On 06-NOV-2003
mqsash 
Since Sun is not releasing Tiger (v1.5) anytime soon, we have 
decided to stop the porting to Suns JVM.  Instead we are 
moving to C#.


Submitted On 25-DEC-2003
bertung 
No need to wait for tiger anymore, as of 1.4.2_03 
plugin problem has gotton worse. Not instead of 
getting stack overflow, we are getting the following

java.lang.NullPointerException

	at 
sun.plugin.javascript.ocx.JSObject.setIExplorerAppletC
ontext(Unknown Source)

	at 
sun.plugin.com.DispatchImpl.convertParams
(Unknown Source)

	at sun.plugin.com.DispatchImpl.invokeImpl
(Unknown Source)

	at sun.plugin.com.DispatchImpl$2.run
(Unknown Source)

	at 
java.security.AccessController.doPrivileged(Native 
Method)

	at sun.plugin.com.DispatchImpl.invoke
(Unknown Source)

java.lang.Exception: java.lang.NullPointerException

	at sun.plugin.com.DispatchImpl.invokeImpl
(Unknown Source)

	at sun.plugin.com.DispatchImpl$2.run
(Unknown Source)

	at 
java.security.AccessController.doPrivileged(Native 
Method)

	at sun.plugin.com.DispatchImpl.invoke
(Unknown Source)

A job well done guys, keep up the good work. We had 
find a workaround for that stackoverflow by delaying 
events. But hey Java team is out here to screw the 
customers for the next release over. If there is a 
workaround, they are out here to make it unusable.


Submitted On 12-MAR-2004
korsvall 
I just installed 1.4.2_04 that contains this fix. Now our
application that previously worked fine hangs frequently. 
When we do a JavaScript->Java->JavaScript call, Internet
Explorer hangs more than 50% of the time. It hangs until you
right-click on the application in the task bar. When you do
that, the call finishes and Internet Explorer gets
responsive again, until it hangs next time. 

I guess it has something to do with pumping messages as
mentioned in the evaluation above. Our applet runs in a one
frame and modifies the dom in another frame. Maybe the
messages are not being pumped for all frames? (i'm only
guessing here)

This is a pretty serious issue, as there is no way we can
get our application to work on 1.4.2_04.


Submitted On 17-MAR-2004
korsvall 
After additional testing, we see that the problem above only
occurs in Internet Explorer 5.0 and 5.5, not in IE 6.0.


Submitted On 19-MAR-2004
bertung 
Have you tested this fix with IE5.0 and IE5.5? We have 
started to get 99%CPU usage on our very well working 
liveconnect applications while creating frame or iframe 
inside the document body as of 1.4.2_04 using both 
IE5.0 and IE5.5. However it doesnt do it on IE 6.0. The 
problem is very severe and we see it on all operating 
system versions when IE 5.0 and IE 5.5 is used with 
1.4.2_04. I cant believe it. In every release, something 
is getting out broken with liveconnect. Who is QA'ing 
these products.


Submitted On 19-MAR-2004
bertung 
The problem I mentioned is with 
Java -> Javascript. Why dont you guys do us a favor 
and bring back the latest and greatest plugin release  
JRE 1.4.0 (no,_01,_02, plain 1.4.0). It was the best java 
plugin Sun has ever released. 

You are crippling every effort we are conducting to keep 
up with the all new bugs introduced in every release, 
causing us to spend considerable amont of time, 
money, man power plus costing us our customers 
believing that the problem is with our software. 

So tell us, Where is the problem here?


Submitted On 19-MAR-2004
bertung 
korsvall, you are right; pressing the right mouse button 
on the applications taskbar icon delivers the calls.

I am curious if they are going to REOPEN this bug, or 
we need to file a new bug for this?


Submitted On 22-MAR-2004
korsvall 
Is someone from Sun still watching this bug? Would you like
me to file a separate bug on this, or are you already
tracking the problem? I would very much like to see it fixed
in 1.5, as the bug is present there too.


Submitted On 24-MAR-2004
bertung 
Looks like bugs are closed to be not reopened 
anymore. Korsvall, would you also inform this bug with 
a comment when you file the new bug.

regards,


Submitted On 14-APR-2004
manual63 
--quote--

The behaviour as it is now is in fact not bad, because it
does not freeze browsers when a javascript calls a java
method which then needs long time to process. With 
java 1.3
or below it will freeze browsers.

But with the bugfix #4516042 javascript-java is not
synchronized anymore and this results most of the 
time in a
very bad behaviour of a webablication.

e.g: User clicks on an html button which executes an
javascript-to-java call. The call would need e.g 5 
seconds
to be returned. In the same time the user can easly 
click on
an other button which then executes an other call. If this
call needed data from the first call, it will not have the
data because the first call has not been returned! This
results in most of the time in a complete mess ;-(

can you fix the bug in a way that it will not freeze the
browser.-> browserwindow can be moved and resized 
but no
html element and/or  javascript functions can be 
executed
before the result has been returned?

--quote--

This is exactly my problem now with 1.4.2_04. I have 
JavaScript making a call that gets data from a 
webservice and fills in a drop down on the client and at 
the same time I make another call to draw a chart to 
the left. Some info is needed from the first call to do the 
second, like the customers default in the dropdown, 
but it looks like they are both making a request and the 
processor goes up to 100% and locks my browser. 
What's really strange is that if I righ click the browser in 
the task bar (Win XP) the page redraws and everything 
starts working again. The same applet worked great in 
1.4.2_03, but in 1.4.2_04 it now locks up and has this 
strange behavior.

I don't like it and I might have to rewrite my JavaScript 
with setTimeout methods that wait till one process is 
done until it moves to the next Java request....what a 
pain!


Submitted On 16-APR-2004
ChristianO 
This fix has broken our signed applets since 1.4.2_04 at
least. I think the fix is ok, but before the bug was making
the applet run  with all permission in  these case if
granted. Now I need to modify my applets to make it work
again. Our clients, will see the applet as broken again when
they  will update there JRE.
Is it really impossible to run the application code with all
permissions if the user has  grant  all of them.


Submitted On 19-APR-2004
bertung 
We have confirmed that our implementation was 
causing problems. We have changed our design and 
everything is groovy again. it is a good fix after all.


Submitted On 22-APR-2004
dlmca 
I am still seeing this problem in version 1.4.2_04 :(
My app is using a jPost applet to shuttle data between 
a jsp and the server to avoid unneeded page 
refreshes. If I perform several actions in quick 
succession, the javascript calls to my applet get out of 
sync and the data on my jsp gets all mixed up (values 
move between displayed entity rows, etc.). What a 
mess!


Submitted On 28-APR-2004
jfallot 
bertung,

we are experiencing the issue of CPU stucked during 
liveconnect call, where the workaround is to right-click 
on the application in the XP taskbar.

Can you precise us how did you redesign your app to 
avoid that issue? This will greatly help us in reviewing 
our design.
Thx.


Submitted On 11-MAY-2004
korsvall 
bertung and jfallot, did any of you find a workaround? I
would be very interested to hear more about this.


Submitted On 07-SEP-2004
cheong.gan 
1. This asynchronous behaviour can also account for the mysterious "Stack overflow at line:0" popup window. It looks like javascript engine's stack that is overflow, not JVM. This overflow can be reproduced using the the testcase given: click on "option 3" 10 times in rapid succesion and wait a few seconds for the popup.
2. The stack overflow is readily manifested if you have onmousemove event calling a java method. It wasted 3 weeks of my development effort to figure out why it did not have in the trustworthy microsoft JVM 1.1.4!
3. Could anyone from sun provide away of forcing the use of JVM1.1.4 using <applet> or <object> tag? I do not want user to do manually disable of plugin from IE tools->advance for my applet and then manually enable it again for other applets.



PLEASE NOTE: JDK6 is formerly known as Project Mustang





About Sun  |  About This Site  |  Newsletters  |  Contact Us  |  Employment
How to Buy  |  Licensing  |  Terms of Use  |  Privacy  |  Trademarks
 

 
Copyright 1994-2008 Sun Microsystems, Inc.
A Sun Developer Network Site

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.
 
XML Content Feeds