Closed Bug 115998 Opened 23 years ago Closed 20 years ago

java - javascript onLoad event should fire after applet's init method

Categories

(Core Graveyard :: Java: OJI, defect, P2)

Product:
Core Graveyard
Component:
Java: OJI
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: oliver.jehle, Assigned: yuanyi21)

References

Details

(Keywords: testcase, Whiteboard: redesign, fixed_in_tiger)

Attachments

(8 files)

tests with blackdown jdk also failed.... the correct error message from javascript console included
239 bytes, text/plain
Details
patch
882 bytes, patch
Details | Diff | Splinter Review
source code for trivial test case applet
228 bytes, text/plain
Details
HTML test case that uses the applet above
500 bytes, text/plain
Details
A workaround for the bug
771 bytes, text/plain
Details
Alternative work around
314 bytes, text/plain
Details
the html code
512 bytes, text/plain
Details
the applet code
349 bytes, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+) Gecko/20011218 BuildID: 2001121808 java-javascript handling is different on windows/linux The Problem is, that the same html/java combination works with windows mozilla (build 2001121803) .. with the linux version, the access to the java method fail and you will get on the java script console error messages, that the function hasn't any properties. when you reload, the methods will work sometimes, sometimes not... the used jdk version is 1.3.1_01 / from SUN with the plugin and on windows is 1.3.1_01a I don't know if it's a java problem or a mozilla problem, but it looks, that the onload statement is comming back before the java is ready i've put my example in additional information, because i've seen no possibility to put it somewhere on the net Reproducible: Always Steps to Reproduce: 1. save the master.html/testf.html and HelloWorld.java as seperate files to your sytem 2. use java1.3.1 to compile HelloWorld.java with javac HelloWorld.java 3. open master.html with mozilla Actual Results: you will get a working version on windows, but not on linux use java plugin 1.3.1_01a from sun on windows 1.3.1_01 from sun on linux Expected Results: like in windows.... display the applet and use the java methods ------------------------------ master.html ------------------------------ <html> <script language="JavaScript"> function setNames(name) { frame1.setFrameName("frame1"); frame2.setFrameName("frame2"); frame2.document.applets["hello"].setFrameName("frame2_c"); } </script> <head> <title>Test</title> </head><html> <head> <title>TestFrame</title> </head> <frameset rows="50,50" onLoad="setNames()"> <frame name="frame1" src="testf.html" name="frame1"> <frame name="frame2" src="testf.html" name="frame2"> </frameset> </html> ------------------------------ testf.html ------------------------------ <html> <script language="JavaScript"> function setFrameName(name) { document.applets["hello"].setFrameName(name); } function set() { myString = new Date().toLocaleString(); document.applets["hello"].setText(myString); } function setSize() { document.applets["hello"].setSizeFromFrame( document.body.clientWidth, document.body.clientHeight); } </script> <body> <h1> testframe.....</h1> <form name="testform"> <input type="button" value="Test" name="clicker" onClick="set()" /> </form> <Applet width="200" height="200" id="hello" name="hello" code="HelloWorld.class" codebase="." mayscript="true" scriptable="true" </Applet> </body> </html> ------------------------------ HelloWorld.java ------------------------------ import javax.swing.*; import java.awt.*; import java.util.*; public class HelloWorld extends JApplet { String myString = new String("Hello, world!"); int id = -1; String frameName = ""; boolean red = false; static Hashtable applets = new Hashtable(); static int counter = -1; JTextArea area = new JTextArea(myString); public void init() { id = ++counter; System.out.println("Init Applet with id = "+id); applets.put(id+"",this); area.setRows(20); area.setColumns(80); this.getContentPane().add(area); } public void setSizeFromFrame(int width,int height) { System.out.println("applet "+id+" "+"width "+width+" height "+height); } public void paint(Graphics g) { } public void switchColor() { if(red) area.setBackground(Color.white); else area.setBackground(Color.red); red=!red; } public void setFrameName(String name) { frameName = name; System.out.println("Framename : "+name+" id :"+id); } public String getFrameName() { return frameName; } public String getId() { return id+""; } public String getText() { return myString; } public void stop () { applets.remove(id+""); } public void setText(String aString) { myString = aString; applets.put(id+"",this); int i = 1; String printout=""; String key; String output; HelloWorld tmp; for(Enumeration e = applets.keys(); e.hasMoreElements();) { key = (String) e.nextElement(); tmp=(HelloWorld) applets.get(key); printout = printout+key+" "+tmp.getFrameName()+" "+tmp.getText()+"\n"; if(!tmp.getFrameName().equals(frameName)) tmp.switchColor(); } System.out.println(printout); area.setText(printout); this.getContentPane().repaint(); } }
i've done also a test with blackdown jdk1.3.1 --> the same result as with the jdk from sun i've forgotten to attach the error message from the javascript console here it is: Error: document.applets.hello.setFrameName is not a function
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is this related to bug 2874? That bug was opened back in 1997... ;-)
I've verified that onload is fired before the applet has finished it's init() method. This is on Windows using Mozilla 0.97.
don't know if there is a defined rule that says when the oninit will return... but with the sample you can see, that the event handling of the windows java plugin is different to the linux java plugin. i've tried to debug the problem with the source code of the java plugin, but i can't download it, because sun people don't know about small countries in europe like liechtenstein and so i can't download the source code from my location :-))) i think, when this error is fixed, a lot of other liveconnect probles will be solved...
Severity: major → critical
Done tests with the build 2002021308 and the release jdk1.4.0 jdk / plugin ... same results :-((( the sample not working !!!! and after some relaods and do the tests, the browser dies with a talkback dialog.. following the some details of the talkback output : [ E90] 2D 62 69 6E 00 11 41 56 41 5F 50 4C 55 47 49 4E [-bin..AVA_PLUGIN] [ EA0] 5F 53 54 41 54 45 31 34 30 00 30 78 38 32 31 61 [_STATE140.0x821a] [ EB0] 66 62 30 00 [fb0.] Event Description Unix exception Event Type 1 (0x00000001) File Size Limit (Hard) 2147483647 (0x7FFFFFFF) File Size Limit (Soft) 2147483647 (0x7FFFFFFF) Group ID 100 (0x00000064) Heap Limit (Hard) 2147483647 (0x7FFFFFFF) Heap Limit (Soft) 2147483647 (0x7FFFFFFF) Heap Size 3353710056 (0xC7E58DE8) Information Collection Time 02/14/02 01:48 PM UNIX Signal 11 (0x0000000B) User ID 500 (0x000001F4) Statistics Application Crash Counter 3 (0x00000003) Application Launch Counter 4 (0x00000004) Application Quit Counter 1 (0x00000001) Application Running 0 (0x00000000) Application Unknown Quit Counter 0 (0x00000000) Count of Information Collections 3 (0x00000003) Seconds Since Last Crash 51 (0x00000033) Total Runtime Seconds 275 (0x00000113) Use Seconds Since Last Crash 1 (0x00000001) System Information CPU Information ? model 8 vendor GenuineIntel stepping 3 bogomips 1500.77 Page Size 4096 (0x00001000) Platform Type 1610612736 (0x60000000) Processor Speed 134622292 (0x08062C54) System Information Linux vorab 2.4.17 #1 Mon Jan 28 09:46:03 CET 2002 i686 System uptime 1:48pm up 3:45, 1 user, load average: 0.69, 0.42, 0.22 Total System Memory 525668352 (0x1F551000)
Oliver, one question : Is the bug reproducible if you change the last string in the following function: function setNames(name) { frame1.setFrameName("frame1"); frame2.setFrameName("frame2"); frame2.document.applets["hello"].setFrameName("frame2_c"); } Instead of 'frame2.document.aplets....." use 'frame1.document.applets...." ? It is definitely NOT fix or workaround it's just the question. I have some considirations about this bug and I'd like to check them.
Hi Sergey it makes no difference,witch frame you take for the examle... i've done some more testing and found a workaround, running my examples, but a intranet solution, based on java-javascript, i cannot change, relay on it... the problem is, that the applet call will came back, before the init of the java applet is done and ready to accept method calls. the workaround is, to ignore onInit in HTML and make a call back from java to javascript, that the applet is initialized...
Attached patch patch — — Splinter Review
Patch is not tested well.
I think that the reason of the bug is: loader of root document (root frame) doesn't have information about completed/noncompleted loading of plugin. I created attachment #70922 [details] [diff] [review]: it is patch that fixes the bug. I'm not sure that fix is correct because I have not good testbase. I think that this is not OJI bug but this is plugin bug. Oliver, would you please check the fix ? Serge, would you please look at this bug and patch ?
hi serge.... i've downloaded the source of the latest nightly build and patched the file... , get the html and java source from this bug and the error still occurs.... i think, the master will wait until the frames are loaded, but in the frames onInit is fired before the plugin is initialized and the java methods are available... i can mail you the samples as files if you want for testing... but they are also in the bug discription and should work the console log.... For application/x-java-vm found plugin /usr/local/j2sdk1.4.0/jre/plugin/i386/ns610/libjavaplugin_oji140.so For application/x-java-vm found plugin /usr/local/j2sdk1.4.0/jre/plugin/i386/ns610/libjavaplugin_oji140.so JavaScript error: file:///home/oj/tmp/testjava1/testf.html line 4: document.applets.hello.setFrameName is not a function Document file:///home/oj/tmp/testjava1/master.html loaded successfully
Oliver, would you please look at patch for bug #106253 ? If it fixes this problem it is possible to close this bug as dup of #115998.
It looks really that this bug is a duplicate of 106253. i tried to patch the 2802 mozilla trunk source with the patch in the bug 106253, but without success, the sources and the patch differs to much... i will monitor 106253 ... thanks for helping... *** This bug has been marked as a duplicate of 106253 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
looks like 106253 only helps with non java plugins... i've written the following note to bug 120774: the problem is, that javascript cannot reference to java-methods until the java object is initialized.. but mozilla triggers the onInit() to early, after starting the plugin, not after initializing the java object. so you always get java-script errors on the javascript-console... i've opened a bug 115998, but then, somebody tells me to have look on bug 106253... it describs the problem also, but fix it only for not java-plugins :-((
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 2874 has been marked as a duplicate of this bug. ***
The onload event handler firing before the applet loads is a big problem for my firm. I wanted to request a solution to this bug if possible as it is critical to my firm's upcoming product release. We are planning on deploying the product to all platforms utilizing the mozilla browser. Interestingly this problem exists on all platforms (Windows, Linux etc).
Setting Priority to P2 based on Comment #15 above -
Priority: -- → P2
can you include this bug in the to do list for release 1.0 ??? i think, this will be important for all users of solutions using java applets and mozilla... in the commercial environment its a stop/go desicion for IE and against Netscape6/Mozilla because the solutions in the intranets have (if there are) the need to use java with javascript.... and onInit is the point, where they synchronize and start the webapplication (as i seen in some customer projects).
I wanted to point out that in many cases the browser does crash or hang when the page loads (onload is called) before the applet completes loading. I did not see this mentioned anywhere on this page.
It's correct, that the browser crashes... but mostly in my case, when you do a reload of the page some times... i've added long time ago the talkback output of such a case... :-) i'm still wondering, if netscape 6 also contains this bug and noone has fixed it. There are a lot of solutions around using the onload flag, and a lot of people must use MS$-IExplorer and Windows, because the application will not be usable with mozilla or netscape 6.
I am including a stack dump from Visual Studio. This occurs on a page that when loaded uses a JavaScript function to poll an Applet. NTDLL! 77f8e103() NTDLL! 77f9f062() JPINS32! 027e7888() JPINS32! 027e6bb1() JPINS32! 027e5c55() OJI! 608b3c74() OJI! 608b3dc6() JSJ3250! 60d089de() JSJ3250! 60d03cfd() JS3250! 60cd3988() JS3250! 60cc7479() JS3250! 60cc6f3d() GKCONTENT! 601f37c9() DOCSHELL! 6012ab23() DOCSHELL! 60121891() DOCSHELL! 60129e0f() DOCSHELL! 6012192d() DOCSHELL! 6012eef2() URILDR! 60b65525() URILDR! 60b6521d() NECKO! 6083a110() SETUPAPI! 778b0c24()
As i know, the window.onload event will be fired when a html page has been loaded (or exactly, the html text has been loaded), but does not wait until the plugins has been loaded. To know now when an applet has been loaded, just call a javascript function (like appletOnLoad) from the applet start method via liveconnect. Here comes the problem, if you do so on win32 (on Mac 8/9 it works), mozilla will hang and you can only quit the browser then. By quitting the browser it will result in a crash. There is a workaround for this :-), but I would be very happy if this can be corrected so that the workaround is not needed anymore. Please look at my bugreport, there is also an example for the workaround. http://bugzilla.mozilla.org/show_bug.cgi?id=128037
comment for <21> the solution you suggested works.. really.. i've done also a workaround.. but i can't change an application sold by another company and they are not willing to change the code, because, when using the workaround with other browsers, they crash them und using the devil (iexplorer) works. so for them the solution is easy... use it and it works. if mozilla should be a good alternative for the devil, then it should work with like the devil, because all companies developing a solution, will develop it to work with iexplorer, when you have luck, in java and javascript, so you have the chance that it works with mozilla... but they won't spent a lot of money to find workarounds for such problems, looking like bugs, not standards...
Is there a plan to fix this bug for an upcoming release version i.e 1.1 or 1.2? Thanks
Blocks: 145775
No longer blocks: 145775
Summary: java - javascript handling is different / looks that onload returns before applet is initialized / windows version works well → java - javascript handling onload returns before applet is initialized
I'd like to reiterate what's in some of the comments here and in particular #15. This bug should really be fixed. That is, there MUST be a RELIABLE way to call Java applets from Javascript as simply as it is for IE on windows. Without this capability, Mozilla is only half there as a reliable browser. Please consider: 1) fixing as soon as possible. 2) fixing/verifying related bugs - 145775 Crash when loading /unloading page with applets - 139789 java applets crash in multiframe page - 136285 applets crash browser - 94801 Running many applets consecutively will cause browser crash
i've changed the title and upgraded severity of this bug ! I think the priority of this should also be increased. it's looking like a blocker for using Mozilla/Netscape in some commercial solutions on the market and for users buying this solutions (or companies who looking for a better browser then netscape 4.7x and IExplorer). please Mozilla Cracks, have a short look on it !!
Severity: critical → blocker
OS: Linux → All
Another peculiarity is that if you set a Javascript variable equal to the applet before it has loaded then it never gets updated once the applet has loaded even when you re-assign it. For example: <body onload="init()"> <script> var app = null; var tmout = 0 function init() { app = top.frames[0].document.myApplet; if (! app.init) { if (tmout > 0) clearTimeout(tmout); tmout = setTimeout("init()", 200); return; } else if (tmout > 0) clearTimeout(tmout); alert(app.init); app.useSomeMethod(); } </script> The app variable never gets updated to reflect the loaded applet after it has loaded. Unless of course this is due to some deficiency of my understanding of Javascript which I have not used all that much.
Priority: P2 → P5
Priority: P5 → P3
Why has this bug priority be lowered from P2 to P3? Isn't someone reading the comments in here. If only one thing the priority should be INCREASED not decreased!!!
i've changed it to have a short look, if there is someone who's also waiting for a solution of this bug.... i have opened this bug december (and replaced bug 2874 opened in 1997) and think, its an important one, but it's my opinion.... so if you #27 also wait for a solution... try to assign a p1 priority to the bug... i hope, the responsible for this bug can make a note if there are plans to fix this case or not... (perhaps a target milestone....) if not, we know, that we can't use mozilla for this kind of javascript-java applications.... and have not to wait for a solution....
Priority: P3 → P2
Thanks for resetting it to P2. I would like to make it a P1 but I can't since I am not the owner of the bug nor a sufficiently privileged user. If you'd like to set to P1: cool. As stated in #28, can someone at Sun or Netscape specify whether there is any plan on investigating that defect, fix it or just close it as is. At least we'll know if we can rely on Mozilla for this kind of solution...
Belive me or not, but the javascript-java-javascript communication stuff is very important for next generation application (applications not websites!) on the net. Because in IE liveconnect does only work on win32 systems, mozilla is very important and would also include other os's (mac, linux,...) At the moment, mozilla can be used for liveconnect stuff, but you need to make a lot of workarounds. If liveconnect is going to be rewritten (http://bugzilla.mozilla.org/show_bug.cgi?id=59686#c64), then this bug should also disappear. (hopefully)
#29 i will set priority to p1...
Priority: P2 → P1
Did some testing, and fould out that this is a timing issue, which is exactly the same problem that 2874 was talking about. The cause of the problem is that the onCall event is fired before applets finished loading. If you delay the onCall a little bit, for example by modifying the setNames() in master.html in the test case (see below), the error will not occur. Therefore, the problem seems to be that the event handler somehow let onCall jump the gun. Why Windows does not have this problem? One possible reason is that on Windows, JVM is in the same process as the browser, whereas in Unix a separate process (since netscape 6). Re-assign to event handler, the owner of 2874. ============================================= Modified master.html to delay onCall(): <html> <script language="JavaScript"> function setNames(name) { setTimeout("frame1.setFrameName('frame1')", 3000); setTimeout("frame2.setFrameName('frame2')", 3000); setTimeout("frame2.document.applets['hello'].setFrameName('frame2_c')", 3000); } </script> <head> <title>Test</title> </head><html> <head> <title>TestFrame</title> </head> <frameset rows="50,50" onLoad="setNames()"> <frame name="frame1" src="testf.html" name="frame1"> <frame name="frame2" src="testf.html" name="frame2"> </frameset> </html>
Assignee: joe.chou → joki
Status: REOPENED → NEW
Component: OJI → Event Handling
I believe that puting a little break on onCall (for instance as shown in the modified master.html) could be used as a work around. There seems no need to rush calling applet functions before they are ready anyway. Therefore, change severity to "critical" and priority to 2.
Severity: blocker → critical
Priority: P1 → P2
#32 thanks for answering :-))) it looks, that it was only a special case, that works with windows... the machine was very slow... on faster windows machines, its the same problem as with linux... there is also another workaround, fire an action from java to javascript as last function in the init() method.... but i think, these are all workarounds, not solutions for the problem !!!
in most cases the call from the applet init method will result in a crash. the only workaround which works 100% is to use a thread. please look at http://bugzilla.mozilla.org/show_bug.cgi?id=128037 where I described the workaround.
I just want to confirm comment #26; once I try to access the applet from JS before it is loaded, I can no longer access it in the web page (e.g. from a button onClick event). Also, the usual setTimeout() trick to wait until the applet is loaded does not work.
joki not around, --->taking bug So as part of the fix to bug 136927, I have the ability to easily delay the onLoad handler which is what I think is needed to fix this bug. So, does anyone what browser function causes the applet's init method to fire? How can the browser know when the applet is ready for onLoad to fire?
Assignee: joki → peterl
Question: What is the definition of the window.onload function? 1.) When html, pciture and plugins have been loaded 2.) When html and picture data have been loaded. 3.) other? -If anwser is 1, then the onload event should be delayed (ie and ns4x does not works so). -If anwser is 2, then it is the plugins job to tell the browers when the plugin has been loaded (ie and ns4x works this way, at least for javaplugin). At the moment this does not work. Please see Bug 115998. I have generated a lot of crash data for this bug and I can reproduce it on win32 systems. -if 3?
#38.. i think this is not a question what standard is, because if you are end-user, you working with a browser supporting all applications, and if mozilla doesn't, you dont use it !!! sorry, but sometimes the techical view of things is not the same as the end-user view.... #37 i hope, joe.chou#eng.sun.com or someone of the java-plugin-developers can help you !!
I'm not so intrested in knowing the standart but I think that if one thing works in may similar environments (browsers) other similar enviroments (mozilla) should also work the same. As an software developer (mozilla-end-developer) I'm more concerned that I don't need to write the same thing in may diffrent ways (as it is at the moment). I belive that mozilla is the best environment for the type of application I'm writting, but there are still some issues (like this one) that needs to be fixed. So I'm investigate time to write bugreports that those bugs are going away. (If I write code and mozilla is going to crash by this code, then its a bug for me.)
sorry it should be bug 128037 in #38. it was tooo late in the night....
QA Contact: pmac → petersen
As someone who writes about and programs with Java and JavaScript, I'd like to add my opinion that this is a serious bug that needs to be fixed! I don't believe there is a standard about when onload is triggered, but in the past, with other browsers, it was not triggered until after the applets were initialized. Note that for many pages it is not necessary to defer the onload in this way. What we really want is a guarantee that any LiveConnect calls made after the onload handler is triggered will succeed. Instead of always deferring the onload handler for all pages, a fix could simply have LiveConnect calls wait for initialization when necessary. (This is just a theoretical approach; I know nothing of the code base, so I don't know how practical it is.) In the meantime, while we're waiting for a fix, I'll attach a simpler test case that demonstrates the bug, and also the workaround that I use for it.
This is the source for the applet I use in my test case. HTML file follows.
This is the HTML code that uses the previously-attached applet to demonstrate this bug. The code should display "Hello World" but instead it displays a TypeError exception. This is attached as text/plain because you've got to download it and compile the applet yourself in order to try it out: you can't just run the test directly from bugzilla. The next attachment will be a workaround
This is a modified version of the test case that demonstrates my workaround. Basically, I just keep polling the applet until it responds, and trap any exceptions that are thrown when it doesn't. The weird thing is that because of some kind of apparent caching, I've got to repeat the call to document.getElementById() to look up the applet each time I poll. Also, and this seems to be critical, I've got to save the resulting element object in a local variable inside my function. If I save it to a global variable (e.g. by deleting the "var" keyword from the code shown here) then this workaround does not work and the applet never responds. Please note: this attachment and the previous two have been tested with Mozilla 1.1 on Linux only. I haven't tried other versions or other platforms.
Thanks for the testcase David. Reading back over the bug and testing in Netscape 7 and today's build, I see this is not a problem on Windows. Furthermore, Joe is right in comment #32, that this problem is likely caused on UNIX only because the JVM uses a seperate process. Since it's only UNIX that has the problem, I don't think we can fix this in the browser. --->reassign to Joe in OJI. However, Sun may be able to fix this in their plugin by adding a dummy request to the channel as I'm doing in the patch in bug 136927. If the applet added the request to the load group when the browser calls init, then the onLoad event would not fire until the applet removed the request from the load group after it calls init. nsILoadGroup and nsIRequest are even frozen.
Assignee: peterl → joe.chou
Component: Event Handling → OJI
Keywords: 4xp, pp, testcase
QA Contact: petersen → pmac
Summary: java - javascript handling onload returns before applet is initialized → [unix] java - javascript handling onload returns before applet is initialized
i've tested it soon on a mozilla (i think it was 1.0) on a very fast cpu on windows but there was the same problem... the applet wasn't loaded when javascript calls it... there are some comments from windows users also here... so i don't think its only a unix bug.... when i opened this bug last year, i also think its only a linux bug. but after using mozilla under windows for about a week, i have the same probleme there too(not as often as under linux).
I have found in the past that try{...}catch doesn't work reliably on all browsers I want to support. Here is an alternative which seems to work without relying on exception handling. The idea is that if there is an exception the timeout doesn't get canceled. At least it might work on a different subset of browsers:-)
to #46 posted by Peter Lubczynski. With this kind of problems, you can't just try once or twice and conclude that's a unix only issue just because you can't reproduce the problem. It can just be a timing issue. We have seen this problem with Mozilla 1.0 on windows. The reality is that there is NO RELIABLE WAY YET to call applets from javascript with Mozilla. We have never seen this issue with IE. If you really want to be serious about this issue, please define what the mechanism for calling applet should be once for all and make sure it is designed, implemented and tested.
okey i did some more testing on this. following was my result: window.onload event was fired after applet.start method on: win32 + ns4.x + netscape vm win32 + ie4+ + ms vm window.onload event was fired before applet.start method on: win32 + ie4+ + sun vm 1.4.x+ win32 + moz 0.9.8+ + sun vm 1.4.x+ mac osX + moz 1.2alpha + mrj vm 1.0 test it out yourself, i put a thread.sleep in the applet.start method to simulate a long loading time. calling a java method from javascript can only be done when the applet.start method has finished. http://www.freshjuicymelons.ch/SyncTest.html
Attached file the html code —
Attached file the applet code —
copy replace applet.start with applet.init... sorry.
okay, yes, if you delay the thread calling start() and init() with a Sleep(), you'll get the same problem on any OS that you seen on UNIX. That should really be another bug because the simple testcase works but since I think the problem can be fixed in the same way as UNIX, it's probably better just to note that here. The basic problem is that the Java plugin doesn't put a hold on the load group so onLoad will fire when layout is done reflowing the plugin. If init() is delayed in any way, such as being called from another process as in UNIX or by using a Sleep() as in the tescase in attachment 102926 [details], onLoad will fire first. I'm still seaching for a way for the browser to detect when init() is done because I think it's a simple fix on our end but it may not be possible.
Keywords: pp
Hardware: PC → All
Summary: [unix] java - javascript handling onload returns before applet is initialized → java - javascript onLoad event should fire after applet's init method
There must be a signal, in IE its working. Perhaps there is a solution ( a notfications that init is done) in the ie-plugin code, missing in the netscape version ???
Below is what MS documents for finding out if the applet is ready. Thierry. Microsoft introduced the readyState property for many objects in IE4. Here's a page from MSDN: readyState Property -------------------------------------------------------------------------------- Retrieves the current state of the object. Syntax HTML N/A Scripting [ vState = ] object.readyState Possible Values vState Variant that receives one of the following values. uninitialized Object is not initialized with data. loading Object is loading its data. loaded Object has finished loading its data. interactive User can interact with the object even though it is not fully loaded. complete Object is completely initialized. The property is read-only. The property has no default value. Remarks The states through which an object passes are determined by that object; an object can skip certain states (for example, interactive) if those states do not apply to that object. Standards Information There is no public standard that applies to this property. And here's a newsgroup message from comp.lang.javascript dated 1999/08/20: In IE4 & 5 you can check the value of the readyState property of the applet. if (document.applet_name.readyState=="4") { .......... } The problem is that Netscape doesn't recognize the readyState property. I get around this by wrapping this test inside an if(document.all) { }. You still need to deal with the error that ocurrs in Netscape. I'm curious to see what other solutions are offered here. I hope this info is useful to you. Tom
QA Contact: pmac → petersen
Can we get this targeted and fixed in 1.3? What's the hold-up? /be
Keywords: mozilla1.3
rpotts, jst and I talked about this bug today. Delaying onLoad isn't enough because of the case when an applet is created with a document.write and then accessed in the next line we'll fail. This is the same problem as in bug 177195. One idea was for the browser to spin a model event loop if the plugin could return some special code indicating a scriptable interface was available just not ready yet. An alternate idea is for the plugin to do this spinning. For an example, jst pointed me to the code in the IMPLEMENT_SYNC_LOAD #ifdef blocks here: http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp
reassign to me
Assignee: joe.chou → joshua.xia
*** Bug 120774 has been marked as a duplicate of this bug. ***
are there any ideas when this bug will be fixed ??? i ask, because its marked with the keyword mozilla1.3 and the alpha 1.3 is already out :-)))
Whiteboard: redesign?
Whiteboard: redesign? → redesign
*** Bug 185854 has been marked as a duplicate of this bug. ***
Pete... you have set the redesign in the Status Whiteboard... can you give a short comment and the plans ????
Yes, we are going to redesign the JPI and OJI module and want to resolve some problems we have. For this bug, I think we should add some interface for JPI and then we can get to know whether the applet has been loaded. Currently the developer need to do the job in applet himself.
Hello there, There is a emerging 'standard' in the e-learning world, It is called SCORM, soon enough everyone doing an e-learning course is going to be accessing it via SCORM compliant material. Unfortunatly a lot of them are going to be using infernal exploiter cause of this bug. One aspect of scorm is that there must be an object called API in the parent frame of a frameset, the applet runs in the top frame and the course runs in the bottom. Anyhow these courses have an onInit() function that references the applet and starts up the communication mechanism. I'm going to try out the workarounds that are on this page but I would have to say that this is something that is important to get fixed. Just adding my name to the list. --B
*** Bug 206529 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
*** Bug 122464 has been marked as a duplicate of this bug. ***
->kyle
Assignee: joshua.xia → kyle.yuan
Status: ASSIGNED → NEW
*** Bug 197783 has been marked as a duplicate of this bug. ***
This has been addressed in JRE 1.5 release. It will be available sometime next year.
Just tested with plugin from JDK build 1.5.0-beta-b31 on Linux and the bug is still there.
Ok, I investigated it some more and found the issues in Sun's bug tracker: http://developer.java.sun.com/developer/bugParade/bugs/4913050.html Since you need a web account to access it, for sake of simplicity let me quote the most important part here: "Further investigation indicates that this bug CAN NOT be fixed. Here is the reason. Whenever browser tries to use Javascript (JS) to call Java, it first tries to get Java object. In this case, the JS call to Java happens on the onload handler, so actually the applet is not fully loaded. So theorectically browser call should be blocked to wait until the java side notifies that "I am fully loaded" (actually what we did to Windows platform is until applet start method is finished, see detail at bug 4820301 & 4920552). So browser main thread is blocked to wait. Here is the problem, during applet loading stage, Java thread may call back to browser thread to get Proxy information, this in turn post an event to the browser main thread. However, browser is busy waiting for another event (get java object) to finish. A typical deadlock. Is there any solution for this issue on Unix platform? I went to Mozilla IRC to get suggestion. The answer is "throw new innermost event quque which really means try to create a new innermost event quque to process the new event. I tried this solution, it works in the way that the event finally gets processed, however, it created so many other problems such as synchronized issue. As you may know, Mozilla is a single thread apps in the sense that the layout/JS calls happens serializely. So Mozilla is not really ready for dispatch innermost event quque. So my conclusion is we can't fix this issue unless Mozilla provides a safeway to do event preemption. Or find some similar solution as Windows platform (using Window to dispatch Java side request and use AtlWaitWithMessageLoop to wait for the applet fully loaded or applet start method got exceuted)." Seems bad.
Why aren't Sun folks commenting in this bug? It's hard to believe we can't avoid deadlock, or otherwise design things so that onload runs only after applets have started (or failed decisively to load). Nav 3 and 4 did that, and Nav 3 had all of layout, JS, and Java applets in one thread, while Nav 4 had JS in a separate thread from layout and Java applets. In particular, the text "Whenever browser tries to use Javascript (JS) to call Java, it first tries to get Java object. In this case, the JS call to Java happens on the onload handler, so actually the applet is not fully loaded..." begs the question: why is onload running prematurely? Why cannot Gecko use simple counters to defer onload till all applets tallied by their object tags have loaded or failed? /be
Gecko could definately delay onload until applets are ready if Gecko knows when the applets are ready (and presumably it does, somewhere), we do similar things with images, reflow events etc. Read "nsDummyLayoutRequest" :-) The applet code could do all this, even. That however doesn't fix the problem (assuming it is a problem) when inline script tries to use a Java applet before it's initialized. Anyone know if that's also a problem?
jst: any such inline script is buggy, has been since Nav 3 (Nav 2 if using a child frame rather than an applet, expecting it to be loaded synchronously, or at least before the parent or a sibling runs an inline script). The way to synchronize is onload, or these days, with a load event listener. BTW, frame onload runs before parent frameset, etc. (and reverse order for onunload). Do we comply with all of this, except for applets? /be
Sorry, I wasn't clear in my earlier question/comment. It is of course fine for an applet to not be accessable before the page's onload handler is fired, the question is, are we always safe from deadlocks in a case where an applet is indeed accessed before it's loaded. If there are no such problems (which may very well be the case, it's been too long since I've poked at any applet code), then a dummy request in the document's load group while the applet is loading/initialzing seems like all we'd need.
Yeah, sounds like this could be done with dummy requests. Maybe the problem is that this bug was viewed as an OJI bug, when its fix is likely to involve more code in the applet/object helper area. /be
I'm delighted that this bug is getting attention again. Thanks Miloslaw for bringing this up and finding Sun's bug report. Thanks Brendan for championing it! In response to jst's query in #76, I'm afraid that there is still deadlock potential. I have a XUL application that uses an applet. Since I can't rely on onload to tell me when the applet is initialized, I wait for onload() and then poll the applet every 300 milliseconds or so to see if it has set a flag. Sometimes (maybe 20% of the time) the applet fails to start ever. (My only workaround is to add a "Restart" button in the XUL menu which reloads everything. Restarting consistently makes it work, I believe because all the class files are now cached and ready to go.) This is with Moz 1.5 and JDK 1.4.2 on Linux. I have not yet tried the Java 1.5 plugin or Moz 1.6. I have not attended to what is causing the bug, so I don't know how this possible deadlock impacts potential solutions, but I did want to let you know what I have observed.
Hi David -- what you describe sounds like a flat logic bug somewhere in applet or Java vm-land. It's not a deadlock (else there'd be a hang till doomsday). It may well be worth reporting separately. Once this bug is fixed, we may still find that some applets never load, for no good reason, sporadically. Then we'd want to fix that other bug. This bug is about gating the load event on applet init, in general. I hope the two bugs aren't entangled. /be
I think I agree with Brendan on this one. I filed my bugzilla report (185854 - marked as duplicate) on this with a dead simple test case (http://chem-admin.ucsd.edu/~everett/bugzilla/) My test case, like others, has JS looking for the applet in onLoad(). This would look like a classic race condition. I have also tried the following scenarios in order to rule out the simple race condition hypothesis: 1) Have a user initiate the JS call after they see the "Applet ... started" message in the status bar. 2) Load an applet (in order to 'pre-load' the jvm), then A) the classic JS/onLoad() test or B) #1 above. All scenarios fail with the same JS error. Seems to me that if the browser can tell me that the applet has loaded then it should be able to find said applet. Seems like a simple 'notification' problem to me. The amount of time that it can take for the JS system to 'find' the applet can be extraordinarily long (> 50 seconds). I have noticed on occasion that if the browser is "left alone", the "polling" workaround doesn't seem to work, but if one then performs some action, like moving the window, the code 'wakes up'. This makes me think that the notification is actually sitting in an event queue somewhere and the queue isn't being processed correctly. My last tests were conducted on RH8/Mozilla 1.4 and Fedora/Mozilla 1.6 with Sun j2sdk 1.4.2. Thanks to everyone taking an interest in and working on resolving this bug! Everett
(In reply to comment #73) > Why aren't Sun folks commenting in this bug? > I'm sorry that Pete and I just came back from our vacation today and Xiaobin is not in the cc list. I believe Xiaobin has already fixed this in jre 1.5 b32(not b31). The comment quoted in comment 72 was made in 2003-09-27, which means it's just in a middle stage of our investigation. Miloslaw, could you retry this using b32 build?
The usual place - http://java.sun.com/developer/earlyAccess/j2sdk150_alpha/ - only has b31. Where can I get b32?
b36 (beta2) was released internally. so you may not have to wait too long for a more recent build.
Miloslaw, jre1.5 beta was out http://java.sun.com/j2se/1.5.0/. could you try that?
Yes, the problem is gone with build 1.5.0-beta-b32c. I tested it a few times with my bank's site, and it worked perfectly. A big "Thank you!" to everybody involved in fixing this bug.
Blocks: 200372
*** Bug 200372 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Whiteboard: redesign → redesign, fixed_in_tiger
Ok, Java 1.5.0 (or 5.0) is here and fixes it. Shouldn't this bug be closed?
Yes, jre 1.5 is officially released. -> WFM.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 20 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: