Closed Bug 122464 Opened 23 years ago Closed 22 years ago

running Applet with LiveConnect in Netscape6.2.1 using Java(TM) Plug-in: Version 1.3.1, JRE version 1.3.1 Java HotSpot(TM) Client VM suddenly crashes

Categories

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

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 115998

People

(Reporter: amilkowski, Assigned: joshua.xia)

Details

Attachments

(15 files)

first sample html file
431 bytes, text/html
Details
second sample html file
432 bytes, text/html
Details
third sample html file
432 bytes, text/html
Details
test_amstag.html
197 bytes, text/html
Details
test_amstag2.html
197 bytes, text/html
Details
test_amstag3.html
197 bytes, text/html
Details
wrapper.js
712 bytes, application/x-javascript
Details
TestApplet.java
456 bytes, text/java
Details
First-chance exception in mozilla.exe (OJI.DLL): 0xC0000005: Access Violation.
7.87 KB, text/plain
Details
sun vm defect submitted for internal review
6.39 KB, text/plain
Details
The source code of the Applet
1.46 KB, text/plain
Details
This is the class file the applet
1.51 KB, application/octet-stream
Details
The Jar file containing the applet class
1.22 KB, application/java-archive
Details
The main window
437 bytes, text/html
Details
The html of the popup window
383 bytes, text/html
Details
In order to address issue of instability of Netscape6.x running applets with JavaScript-Java communication , I have build a definite skeleton applet that uses java-plug-in and does a sample javascript-java-applet call. Problem of a Netscape6.x browser suddenly crashing (without a feedback form, browser simply is killed as a process completely..) has been reproduced by navigating sample html (nat1.html, nat2.html, nat3.html containing a reference to the same APPLET tag) multiple times. Note that this sample skeleton is a trivial one (containing nothing but one Live Connect call in ~10 lines of code) and in our real situation we rely on magnitude of such a calls thus frequency of crashes is dramatically increased! Note that project was run under Netscape6.2.1 using Java(TM) Plug-in: Version 1.3.1, JRE version 1.3.1 Java HotSpot(TM) Client VM
Attached file first sample html file —
the html file includes IFRAME link to test_amstag.html (also attached) <IFRAME SRC="http://127.0.0.1/adcontroller/html/test_amstag.html" MARGINWIDTH=0 MARGINHEIGH=0 WIDTH=1 HEIGHT=1 HSPACE=0 VSPACE=0 FRAMEBORDER=0 SCROLLING="no"> </iframe>
the html file includes IFRAME link to test_amstag2.html (also attached) <IFRAME SRC="http://127.0.0.1/adcontroller/html/test_amstag2.html" MARGINWIDTH=0 MARGINHEIGH=0 WIDTH=1 HEIGHT=1 HSPACE=0 VSPACE=0 FRAMEBORDER=0 SCROLLING="no"> </iframe>
Attached file third sample html file —
the html file includes IFRAME link to test_amstag3.html (also attached) <IFRAME SRC="http://127.0.0.1/adcontroller/html/test_amstag3.html" MARGINWIDTH=0 MARGINHEIGH=0 WIDTH=1 HEIGHT=1 HSPACE=0 VSPACE=0 FRAMEBORDER=0 SCROLLING="no"> </iframe>
Attached file test_amstag.html —
contains pointer to wrapper.js (also attached) <script src="http://127.0.0.1/adcontroller/wrapper/wrapper.js"></script>
Attached file test_amstag2.html —
contains pointer to wrapper.js (also attached) <script src="http://127.0.0.1/adcontroller/wrapper/wrapper.js"></script>
Attached file test_amstag3.html —
contains pointer to wrapper.js (also attached) <script src="http://127.0.0.1/adcontroller/wrapper/wrapper.js"></script>
Attached file wrapper.js —
contains actual Applet tags
Attached file TestApplet.java —
actual appplet
--> OJI; cc'ing Patrick -
Assignee: rogerl → joe.chou
Component: Live Connect → OJI
QA Contact: pschwartau → pmac
I appear to be having exactly this same problem. Mine was found by having a page with an applet on it, leaving the page and then returning. It crashes about 80% of the time. My test scenario is quite simple: HTML: <HTML> <applet code="TestApplet" name="TestApplet" width=0 height=0/> <SCRIPT language="javascript"> function OnLoad() { document.TestApplet.test(); } window.onload = OnLoad; </SCRIPT> </HTML> Java: import java.applet.Applet; public class TestApplet extends Applet { public void test() {} } The surest way to see it is to set this HTML as the home page and use QuickLaunch. Launch the page, close it, launch it again. On Win2k, the browser disappears. On WinME, it crashes in kernel32.dll on closing the browser the second time.
Additional information: I was using Mozilla 0.9.7 and Netscape 6.2.x on WinME and Netscape 6.2.x on Win2k, SP2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
helper file (cut & paste) consisting of a run of mozilla browser (mozilla 0.9.8, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020203) in the debug mode (compiled from sources, build script attached) using VC6.00 running html page with the applet (ID: 66955) after refreshing the page ones I received an exception "First-chance exception in mozilla.exe (OJI.DLL): 0xC0000005: Access Violation." in the debug window. Attaching 1. stack trace (from VC6.00 debug window) 2. offending method from : /mozilla\modules\oji\src\nsCSecurityContext.cpp (nsCOMPtr<nsIScriptContext> scriptContext = (nsIScriptContext*)JS_GetContextPrivate(m_pJSCX); ) 3. output from debug window. 4. built script used.
the same problem under linux with build 2002020412 and jdk1.4.0-rc-b91, the browser crash without a notice or message. i have opened another issue with oninit() and liveconnect. oninit will not be triggered when the applet has finished the init, oninit returns before, not aiting for the java applets init(). http://bugzilla.mozilla.org/show_bug.cgi?id=115998
Adding Dave Barrowman and Marcio Galli. Talked with the reported (Andrew -> amilkowski@unicast.com) and this is important for them.
OS: Windows 2000 → All
as per recent correspondence between myself and Marcio Galli in which he suggested using latest SUN JAVA VM to run attached test case with, mozilla exhibited a very stable behavior, later switching to our advertising content delivery technology (Unicast Superstitial), no crash or other aberrations from normal functionality were reported. More explicitly OS/VM/mozilla version used: OS: Windows XP VM: Java(TM) Plug-in: Version 1.4.0 Using JRE version 1.4.0 Java HotSpot(TM) Client VM browser ver: Gecko/20011128 Netscape6/6.2.1 however, a point i want to mention is that a choice of Java VM is entirely up to the user, and as our UNICAST technology runs on variety of variations and permutations of user agents/OS/java VM's is fairly imperative for us to somehow resolve this issue even for lower versions of SUN JAVA VM (especially in todays market "run anywhere and anytime" conditions!), as per Marcio Galli suggestion I am also filling a separate defect with SUN Microsystems thanks so far for your great efforts to see this issue resolved/explained!
attachement contains details of defect logged against Java SUN VM 1.3_02 for its incompatibility with the Gecko browser, pending for internal Sun confirmation and validation
I have the similar problem on netscape 6.2.1. Sun's JRE 1.4 doesn't make any difference. I'm using windows 2000 pro.
I have the similar problem on NS6.2.1 Install Sun's JRE 1.4 doesn't make any difference.
This is a very simple applet, which defined a getHTMLData() method, returning a String. This method is called by JavaScript through LiveConnect.
Attached file The main window —
There is a textarea and a edit link on this page. When you click the edit link, it will open a popup window.
This page contains a applet and a save link. when you click the save link, it gets the string from the applet, and sets it to the textarea of the main window. And then close this popup window. This works as designed at the first time. But if you click the edit link on the main window again, when you save and close the popup window again, the main window (and any other windows in the same process) will be closed together. It happens very often, about 95% of time. I tested it on Netscape 6.2.1|JRE 1.3.1_01, Netscape 6.2.2|JRE 1.3.1_01 and Netscape 6.2.1|JRE 1.4 on Windows 2000. There is no difference at all. I don't see any combination can be called "stable".
Priority to P1
Priority: -- → P1
Tried Kevin Zhang's test case on moz099 and JRE 1.4 (downloaded from java.sun.com/j2se) on Win2000, Linux and Solaris, and it seemed working OK. The problem seemed to be fixed there.
I'm still having problems with Javascript-Java communication in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020422 the applet on the page was working with some previous versions of mozilla or J2SDK. It is also working in Internet Explorer 5.5 with JRE 1.4.0 or microsoft JVM and Netscape 4.7. To me it seems to start looping indefinitely on a Java system call for security. Plug-in Java(TM): Version 1.4.0 Utilisation de la version JRE 1.4.0 Java HotSpot(TM) Client VM Répertoire d'accueil de l'utilisateur = C:\Documents and Settings\couellet Configuration du proxy : Configuration du proxy du navigateur ---------------------------------------------------- c: effacer la fenêtre de la console f: finaliser les objets de la file d'attente de finalisation g: libérer la mémoire h: afficher ce message d'aide l: vider la liste de chargeurs de classes m: imprimer le relevé d'utilisation de la mémoire o: déclencher la consignation p: recharger la configuration du proxy q: masquer la console r: recharger la configuration des politiques s: vider les propriétés système t: vider la liste des threads x: effacer le cache de chargeurs de classes 0-5: fixer le niveau de traçage à <n> ---------------------------------------------------- Niveau de traçage fixé à 5 : base, réseau, sécurité, ext, connexion ... terminé. Récepteur de modalités enregistré Référence au chargeur de classes : sun.plugin.ClassLoaderInfo@13a53d, refcount=1 Récepteur de modalités enregistré Référence au chargeur de classes : sun.plugin.ClassLoaderInfo@32efa7, refcount=1 Récepteur de traçage ajouté : sun.plugin.AppletViewer[receiver,0,0,617x367,layout=java.awt.BorderLayout] Récepteur de progression ajouté : sun.plugin.AppletViewer[receiver,0,0,617x367,layout=java.awt.BorderLayout] Chargement de l'applet... Initialisation de l'applet... Démarrage de l'applet... Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/applets/Receiver.class sans proxy Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/applets/Receiver.class avec cookie "JSESSIONID=vxz2tgelm1" Récepteur de traçage ajouté : sun.plugin.AppletViewer[mapApplet,3,27,-6x-30,invalid,layout=java.awt.BorderLayout] Récepteur de progression ajouté : sun.plugin.AppletViewer[mapApplet,3,27,-6x-30,invalid,layout=java.awt.BorderLayout] Chargement de l'applet... Initialisation de l'applet... Démarrage de l'applet... Chargement de http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/applets/Receiver.class à partir du cache Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/navigator.jar sans proxy Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/navigator.jar avec cookie "JSESSIONID=vxz2tgelm1" Chargement de http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/navigator.jar à partir du cache Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator.class sans proxy Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator.class avec cookie "JSESSIONID=vxz2tgelm1" ATTENTION : Impossible de mettre http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator.class en cache Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator.class sans proxy Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator.class avec cookie "JSESSIONID=vxz2tgelm1" Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en.class sans proxy Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en.class avec cookie "JSESSIONID=vxz2tgelm1" ATTENTION : Impossible de mettre http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en.class en cache Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en.class sans proxy Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en.class avec cookie "JSESSIONID=vxz2tgelm1" Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en_US.class sans proxy Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en_US.class avec cookie "JSESSIONID=vxz2tgelm1" ATTENTION : Impossible de mettre http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en_US.class en cache Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en_US.class sans proxy Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en_US.class avec cookie "JSESSIONID=vxz2tgelm1" Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en_US.properties sans proxy Connexion http://www.mapworkspace.st-roch/4.1/ui/custom/navigator/java/com/korem/map/navigator/Navigator_en_US.properties avec cookie "JSESSIONID=vxz2tgelm1" Connexion http://www.mapworkspace.st-roch/4.1/app/tools.nav.server./Ping?mapInstanceKey=2&rnd=java.util.Random@7bc899 sans proxy Connexion http://www.mapworkspace.st-roch/4.1/app/tools.nav.server./Ping?mapInstanceKey=2&rnd=java.util.Random@7bc899 avec cookie "JSESSIONID=vxz2tgelm1" JavaScript : UniversalBrowserRead activé JavaScript : UniversalJavaPermission activé JSObject::eval(var NULL; if(document.receiver != NULL){ document.receiver.receive(document.mapApplet.getMap());}), url=http://www.mapworkspace.st-roch, permission=false JavaScript : appel du code système Java JavaScript : politique de sécurité par défaut = http://www.mapworkspace.st-roch <begin infinite loop here> JavaScript : appel du code système Java JavaScript : politique de sécurité par défaut = http://www.mapworkspace.st-roch <end infinite loop here> In the page I use 2 applets coming from the same origin, one light applet loading fast and displaying a please wait message and a big one that when it have completed a part its loading process take the place of the first applet. In some environment I can switch the applet of container using Javascript in other by the applet context, that is why it try to make a call Java-Javascript-Java. If it fails it try using the applet context, but now it dont have a chance to do it because of the infinite loop.
Our application now seems to work while using RC1 and JRE 1.4 (limited testing).
Reporter, Kevin Zhang, Could you try your test cases with some recent mozilla build(i.e., mozilla 099) and the latest JRE 1.4 (downloaded from java.sun.com/j2se), and see what happens? To setup JRE 1.4, simply copy NPOJI140.dll to plugins directory.
Our application also seems to work now using RC1 and JRE 1.4
For your information, using the workaround reported in bug 128037, my applet is now working with J2SDK 1.4.0 java plugin. I start a thread to call the JavaScript method, instead of calling it directly from the thread calling the start method.
Did some more testing and found that the workaround is working only if the applet and the page comes from the same host. Is it normal that this is not working? If yes, for your information, it is working with all version of internet explorer with the plugin or not and with netscape 4. And in the logs there is some "permission = false" beside JavaScript statements, does it mean the statements are not permitted to execute? JSObject::eval(var NULL; if(document.receiver != NULL){ document.receiver.receive(document.mapApplet.getMap());}), url=http://pns4.pushnsee.com, permission=false JSObject::getMember: name=navigator, url=http://pns4.pushnsee.com, permission=false http://www.pushnsee.com/demo.asp
You can't use javascript for crossdomain scripting. So it's the same for an applet which uses liveconnect (javascript) to communicate with the html page.
This was working before in mozilla 0.9.x some time. The idea behind this is to have one small applet that load fast and display a waiting message. And another big applet that load in the background, and when ready jump into the first applet space . It is working well in other main browsers, but not the newest versions of mozilla. I see 3 possible way to do what I want : 1- using the applet context, if I remember correctly, only works in netscape 4. 2- statically, but it was not working with Internet Explorer and/or Netscape6; 3- via liveconnect and Javascript, I found a way of doing it for internet explorer. Also the Javascript is not coming from another site, it is coming from one applet. Both applets comes from the same codebase URL, but I use the _document_ to communicate between the applets. I also use Java-Javascript call to open window like in 'window.open(...)', I wonder if this either will work if I find a solution to my first problem. Also, about the cross-site scripting over domain, why is it just the applet that is affected, I have the same functionnality using JavaScript and HTML and it works just fine. So I would say the restrictions are greater on Java than on Javascript and HTML, are there any documentation that explain the reasoning behind this behavior, because I find that cross site scripting is a usefull way to reduce cost and complexity in use of web application. And I'd like to know if it is working only until it will be fixed.
Implemented solution 1 it works in Internet Explorer and Mozilla(0.9.++), but I need to use reflexion. I'm not sure will work on Netscape 4.05 and less. And effectively I cannot call "window.open" in my applet, this meaning I cannot call Javascript at all if my applet is not coming from the same host as the page it is embedded in. Is it a bug, or it is working as expected. Calling window.open from Java is usefull to determine the window parameters, Java is somewhat limited in this.
New test from Roger: Win Netscape 7PR1 and WinXP and Java 1.4 (N7 default). The applet hangs in the first click. Someone can confirm this? is this another (new) bug?
Reporter, could you try your test case with NS7.0 pr1 and JRE 1.4.0_01, and see what happens? It seemed working for several people using the later versions.
QA Contact: pmac → petersen
reassign to me
Assignee: joe.chou → joshua.xia
Reporter: Could you please try latest JRE(1.4.1_01) and see whether this is still a problem? Thanks
following configuration has not produced fatal crash as reported: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 with/ Java(TM) Plug-in: Version 1.4.1 Using JRE version 1.4.1-beta Java HotSpot(TM) Client VM User home directory = C:\Documents and Settings\amilkowski Proxy Configuration: Browser Proxy Configuration
Still cannot open a window from the Java applet with JDK 1.4.1_01, even if if it is possible in Internet explorer with same JDK and it is possible with only Javascript. Here a log with Mozilla 1.2.1. Plug-in Java(TM): Version 1.4.1_01 Utilisation de la version JRE 1.4.1_01 Java HotSpot(TM) Client VM Répertoire d'accueil de l'utilisateur = C:\Documents and Settings\couellet Configuration du proxy : Configuration du proxy du navigateur Niveau de traçage fixé à 5 : base, réseau, sécurité, ext, connexion ... terminé. JSObject::call: name=open, url=http://pns4.pushnsee.com, permission=false JSObject::call: name=open, url=http://pns4.pushnsee.com, permission=false JSObject::call: name=open, url=http://pns4.pushnsee.com, permission=false JSObject::call: name=open, url=http://pns4.pushnsee.com, permission=false JSObject::call: name=open, url=http://pns4.pushnsee.com, permission=false
Whiteboard: redesign?
remove crash keyword
Keywords: crash
Whiteboard: redesign?
onload liveconnect problem ->115998 *** This bug has been marked as a duplicate of 115998 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
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: