Closed Bug 90571 Opened 24 years ago Closed 22 years ago

LiveConnect bugs - Trunk M1RC3 crash [@ JVM.DLL | jvm.dll - nsHTMLExternalObjSH::PostCreate]

Categories

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

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: setlur, Assigned: xiaobin.lu)

References

()

Details

(4 keywords, Whiteboard: jpibug, topsite [adt2 RTM])

Crash Data

I am encountering LiveConnect bugs in Mozilla 0.92 and the latest nightly build. I think it used to work in version 0.91 or earlier. I am attaching a test case (applet + html) that illustrates the issues. The test case does 3 things: 1. On load, the html page executes a javascript function that talks to the applet. This does not work in Mozilla, but works in Netscape 4.77. It might be argued that the applet may not have loaded fully yet, but I also tested the JavaScript->Applet communication when the applet was running. It still does not work. 2. When the applet loads, it talks to the JavaScript using JSObject(). This seems to work fine. 3. The applet then establishes an SSL connection localhost and reads the first 100 bytes. This does not work with JDK1.4.0 plugin, but works OK with the JDK1.3.1 and JDK1.3.0_1 plugins. The test case works perfectly in Netscape 4.77. The test can be run by saving the following java code as testApplet.java and the html code as test.html. Access the html page through SSL: https://localhost/test.html Here is the Java code: ============================BEGIN-JAVA-APPLET============================ import java.io.*; import java.net.*; import java.awt.*; import java.awt.event.*; import java.util.*; import java.lang.Object; import java.applet.Applet; import java.applet.*; import netscape.javascript.*; public class testApplet extends Applet { JSObject thisWin = null; public int x = 0; public int y = 0; public void init() { System.out.println("Entering applet's init function"); thisWin = JSObject.getWindow(this); JavaToJS("Hello JavaSript, this is a message from Java!"); try{ doSSLConnection(); } catch (Exception e) { System.out.println("doSSLConnection failed with exception " + e); } } public void printXY() { System.out.println("Got message from JavaScript!"); System.out.println("x = " + x + "; y = " + y); } public void JavaToJS(String message) { Object msgObj[] = {message}; System.out.println("Sending message to Java: " + message); thisWin.call("fromJava", msgObj); } public void doSSLConnection() throws MalformedURLException, IOException, ClassNotFoundException { byte[] myByteArray = new byte[100]; System.out.println("Establishing SSL connection to https://localhost"); URL u = new URL("https://localhost"); URLConnection uconn = u.openConnection(); uconn.setUseCaches(false); uconn.setDefaultUseCaches(false); DataInputStream dis = new DataInputStream(uconn.getInputStream()); dis.read(myByteArray); String replyString = new String(myByteArray); System.out.println("First 100 bytes of reply are:\n" + replyString); dis.close(); } } =============================END-JAVA-APPLET============================ Here is the HTML code for test.html: =============================BEGIN-HTML================================= <HTML> <HEAD> <TITLE>Test Page</TITLE> <META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> <META HTTP-EQUIV="EXPIRES" CONTENT="0"> <META HTTP-EQUIV="Content-Script-Type" CONTENT="text/javascript"> <BODY> This is going to load a test applet that does some LiveConnect and SSL stuff. <APPLET width="210" height="500" align="baseline" name="testApplet" code="testApplet.class" MAYSCRIPT> </APPLET> <SCRIPT LANGUAGE="JavaScript"> <!-- function fromJava(message) { alert(message); } function toJava() { alert("Sending message to Java"); document.applets[0].x = 2; document.applets[0].y = 3; document.applets[0].printXY(); } //--> </SCRIPT> </BODY> </HTML> =================================END-HTML=================================
Xiaobin, can you please investigate this? Thanks,
Assignee: edburns → xiaobin.lu
I am sorry, the HTML code is slightly incorrect. I forgot to include the ONLOAD tag in the BODY tag. Otherwise case 1 will not be executed. The HTML should be: <HTML> <HEAD> <TITLE>Test Page</TITLE> <META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> <META HTTP-EQUIV="EXPIRES" CONTENT="0"> <META HTTP-EQUIV="Content-Script-Type" CONTENT="text/javascript"> <BODY ONLOAD="toJava()"> This is going to load a test applet that does some LiveConnect and SSL stuff. <APPLET width="210" height="500" align="baseline" name="testApplet" code="testApplet.class" MAYSCRIPT> </APPLET> <SCRIPT LANGUAGE="JavaScript"> <!-- function fromJava(message) { alert(message); } function toJava() { alert("Sending message to Java"); document.applets[0].x = 2; document.applets[0].y = 3; document.applets[0].printXY(); } //--> </SCRIPT> </BODY> </HTML>
I am using JRE1.4.0 beta release from Sun and Mozilla 0.9.2 to test the testcase in Redhat 7.0. I agree with the reporter's second and third point. I really saw " Sending Messgae to Java" alert box so the first point you raised before is suspectable. However, I think if you add onload, it should be ok. Also, using JRE1.3.1 with Mozilla 0.9.2 works ok, however, finally it crashes the browser. I changed the bug as Assigned and will work on this to see if this is a plugin problem or browser issue, or both.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Stanley, I tried this with the "latest" merlin build, it does not work. Basically it is a regression because it works with JRE1.3.1. Reassign to you.
Assignee: xiaobin.lu → stanley.ho
Status: ASSIGNED → NEW
Xiaobin, in what way does it work for you with JDK1.3.1? Mozilla 0.92 crashes when I use JDK1.3.1, just as you noticed too. Am I doing something wrong? I would like to point out that it works with the original HTML code that I supplied, but when I use the ONLOAD tag to run the toJava() javascript function, the browser dies. Also, I tried Mozilla 0.92 with JDK 1.4.0 beta, and like you, I saw the alert box "Sending message to Java". But nothing happened on the Java side. It looked like the applet had not loaded yet. After a while there seemed to be some applet activity and it loaded, but then I got some exceptions. Thanks!
Follow bugtraq bug 4479764.
Whiteboard: jpibug
Er, that bug 4479764 does not exist.
I am using JRE1.3.1 with Mozilla 0.9.2. All the dialog pop up and ssl connection was set up and date received. However, after this, the browser crashes. It seems that it was caused by some Javascript invalid dereferencing.
Umm, is this bug being worked on?
SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)
QA Contact: shrir → pmac
Reassign!
Assignee: stanley.ho → xiaobin.lu
Status: NEW → ASSIGNED
This is another bug caused by lazy loading fix.
It is a Java Plugin bug. Some class are missing in Java Plugin side. Will contact Stanley Ho to resolve this!
Even not calling Java function when the applet is onload, still got exeception like: java.lang.NoClassDefFoundError: sun/net/www/protocol/https/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at java.net.URL.getURLStreamHandler(Unknown Source) at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at sun.plugin.AppletViewer.setDocumentBase(AppletViewer.java:678) at sun.plugin.viewer.WNetscapePluginObject.setDocumentURL (WNetscapePluginObject.java:457) java.lang.NullPointerException at sun.plugin.AppletViewer.getCodeBase(AppletViewer.java:827) at sun.plugin.AppletViewer.appletInit(AppletViewer.java:461) at sun.plugin.viewer.LifeCycleManager.initAppletPanel (LifeCycleManager.java:150) at sun.plugin.viewer.WNetscapePluginObject$Initer.run (WNetscapePluginObject.java:275) java.lang.NullPointerException at sun.plugin.AppletViewer.getCodeBase(AppletViewer.java:827) at sun.applet.AppletPanel.sendEvent(Unknown Source) at sun.plugin.AppletViewer.onPrivateClose(AppletViewer.java:614) at sun.plugin.AppletViewer$1.run(AppletViewer.java:593) at java.lang.Thread.run(Unknown Source) I have confirmed that this is a JRE regression bug (Works for JRE 1.3.1 and not for JRE 1.4) and I have filed a bug to JPI team and the sun internal bugtrag bug is 4499449. I will follow the progress of that bug.
Xiaobin, It does not work for me with JDK 1.3.1. The errors I get with JDK1.3.1 are different than the one with JDK1.4. With 1.3.1, the test case crashes the browser. With 1.4, I get the error that you got above. How is it working for you with JDK 1.3.1? Are you using the updated HTML code in the test case that calls the toJava() function on load with the <BODY ONLOAD="toJava()"> tag? In the original test case that I posted, I forgot to include that tag, and the resulting test case might make it seem that everything works.
Without onload method call, it works in JRE1.3.1. This is what I mean regression. I want to solve the problem by dividing and conquering.
The first part (no onload) has been fixed in Merlin-beta2 build.
So after downloading JRE1.4 beta2, without onload() call, the testcase works fine. However, with onload call, the testcase will finally crashes the browser. And here is the stack trace. js_SetProperty(JSContext * 0x03ab10f0, JSObject * 0x028bbf38, long 48526144, long * 0x0012e5e0) line 2528 + 5 bytes js_Interpret(JSContext * 0x03ab10f0, long * 0x0012e798) line 2542 + 1939 bytes js_Invoke(JSContext * 0x03ab10f0, unsigned int 1, unsigned int 2) line 824 + 13 bytes js_InternalInvoke(JSContext * 0x03ab10f0, JSObject * 0x028b3770, long 42706512, unsigned int 0, unsigned int 1, long * 0x0012e978, long * 0x0012e8c0) line 896 + 20 bytes JS_CallFunctionValue(JSContext * 0x03ab10f0, JSObject * 0x028b3770, long 42706512, unsigned int 1, long * 0x0012e978, long * 0x0012e8c0) line 3360 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x03aa2cf0, void * 0x028b3770, void * 0x028ba650, unsigned int 1, void * 0x0012e978, int * 0x0012e974, int 0) line 953 + 33 bytes nsJSEventListener::HandleEvent(nsJSEventListener * const 0x04d69d60, nsIDOMEvent * 0x020b410c) line 139 + 74 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x04d69c00, nsIDOMEvent * 0x020b410c, nsIDOMEventTarget * 0x03aa2d60, unsigned int 1, unsigned int 7) line 1196 + 20 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x04d68220, nsIPresContext * 0x04d5fd40, nsEvent * 0x0012f088, nsIDOMEvent * * 0x0012f040, nsIDOMEventTarget * 0x03aa2d60, unsigned int 7, nsEventStatus * 0x0012f0b0) line 1869 + 36 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x03aa2d50, nsIPresContext * 0x04d5fd40, nsEvent * 0x0012f088, nsIDOMEvent * * 0x0012f040, unsigned int 1, nsEventStatus * 0x0012f0b0) line 599 DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x04dec060, unsigned int 0) line 1087 + 47 bytes nsDocShell::EndPageLoad(nsIWebProgress * 0x03ac23c4, nsIChannel * 0x04d9a370, unsigned int 0) line 3707 nsWebShell::EndPageLoad(nsIWebProgress * 0x03ac23c4, nsIChannel * 0x04d9a370, unsigned int 0) line 893 nsDocShell::OnStateChange(nsDocShell * const 0x03ac0844, nsIWebProgress * 0x03ac23c4, nsIRequest * 0x04d9a370, int 131088, unsigned int 0) line 3628 nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x03ac23c4, nsIRequest * 0x04d9a370, int 131088, unsigned int 0) line 1095 nsDocLoaderImpl::doStopDocumentLoad(nsIRequest * 0x04d9a370, unsigned int 0) line 734 nsDocLoaderImpl::DocLoaderIsEmpty() line 632 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x03ac23b4, nsIRequest * 0x04db9440, nsISupports * 0x00000000, unsigned int 0) line 563 nsLoadGroup::RemoveRequest(nsLoadGroup * const 0x03ac2340, nsIRequest * 0x04db9440, nsISupports * 0x00000000, unsigned int 0) line 511 + 44 bytes PresShell::RemoveDummyLayoutRequest() line 6191 + 42 bytes PresShell::DoneRemovingReflowCommands() line 6147 PresShell::ProcessReflowCommands(int 1) line 5978 ReflowEvent::HandleEvent() line 5764 HandlePLEvent(ReflowEvent * 0x04db93e0) line 5778 PL_HandleEvent(PLEvent * 0x04db93e0) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00d54900) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x0004029a, unsigned int 49357, unsigned int 0, long 13977856) line 1071 + 9 bytes USER32! 77e71820() 00d54900()
I downloaded JRE 1.4 beta 2, but could not get the plugin to work with Mozilla. I used the latest nightly build of Mozilla, and I added the plugin by creatin g a symlink libjava_oji.so to the plugin in jre/plugin/i386/ns600/libjava_oji1.4.so. When I fire up Mozilla, the Java console menu option is greyed out. What do I need to do to get it to work? I tried both J2SDK1.4 beta2 and J2RE1.4 beta2. The earlier beta worked just fine. I use Linux.
Reporter: There is some changes to register the java plugin in Unix platform. We are still working on to resolve this issue. But for now, please try to verify this bug in Windows platform.
I tried the latest Mozilla 0.94 and JDK 1.40 Beta 2 on Windows hitting an Apache server on Linux. 1. HTTPS (SSL) connection from Java applet now seems to work. 2. Java->Javascript also works, but that was never broken. 3. JavaScript->Java is still broken every way I try it.
Couldn't reproduce this bug on Redhat 6.2 and jre 1.4. Mozilla doesn't crash: browser hangs.
Yes, this is a bug of JPI. We are working on it to get it resolved.
Is bug 100151 a duplicate of this one?
How is this one going? As I understand it, the issue is with the Java plugin, not mozilla? Is there going to be a new beta of the JDK1.4?
Take a look at it soon!
Target Milestone: --- → mozilla0.9.6
Here is another test case: http://www.highscore.de/mozilla/getwindow.html It demonstrates the onload-bug which freezes an applet when it tries to access javascript via LiveConnect.
0.9.6 is out the door.
Yup, mozilla 0.9.6 is out, and it seems to work a little better on our server, but not completely yet. For what it's worth, I eliminated all use of LiveConnect in the new version of the code. We were using LiveConnect to communicate between applets, and there are more elegant ways of doing that anyway.
The onload-bug still exists: http://www.highscore.de/mozilla/getwindow.html (tested with Mozilla 0.9.6 and SUN JRE 1.4 BETA 3 under Windows 98) Any comments when this bug will be fixed?
Reassign this to Margaret!
Assignee: xiaobin.lu → mtchan
Status: ASSIGNED → NEW
Moving the Milestone and adding keyword mozilla1.0.
Keywords: mozilla1.0
Target Milestone: mozilla0.9.6 → mozilla0.9.9
WFM on Linux RH 7.1 for trunk build (20020222) with JRE1.3.1_01. Can somebody reproduce this bug with recent trunk build ? If bug is reproducible try patch for bug #106253.
using http://www.highscore.de/mozilla/getwindow.html I crash using build 2002030908 on Win2k + JRE 1.4.0 and also build 2002030108 on Linux + JRE 1.4.0-b92. Talkback ID: TB3846173X (Linux), TB3846098W (Win2k).
http://www.highscore.de/mozilla/getwindow.html still crashs Mozilla 0.9.9 on Windows 98 and SUN JRE 1.4.0 (or Mozilla 0.9.9 hangs and I have to kill it). Target milestone was 0.9.9? Anything we/I can do - better testcases or anything else? I really like to see this bug fixed in Mozilla 1.0 as everything else in LiveConnect works great for me.
Olivier: Your Linux crash at http://www.highscore.de/mozilla/getwindow.html looked a lot like the crash reported in Bug 108121...which I just marked worksforme. If you can still reproduce this crash with a build after 3/4 or with Mozilla 0.9.9 on Linux please reopen that bug and submit your Talkback incidents ids...so we can make sure it's the same crash. Boris: I tried going to http://www.highscore.de/mozilla/getwindow.html with my WinNT build 2002031203 and was able to crash after closing the window (after the site hangs the browser)....but that crash is already logged in Bug 108601.
Xiaobin, since this is a JPI bug, any updates on the fix of this bug yet?
This problem seems only exists on Windows, no matter if JRE is 1.3.1 or 1.4.x. But the problem does not seem to exist on Unix. I tried on Linux (mozilla099 with 1.3.1, the one currently downloadable from Netscape) and Solaris (mozilla 099 with 1.4 and mozilla 098 with 1.3.1), and they all seemed to work fine, and were able to load the test case's URL. Change platform to WindowsNT (actually I tried it on Win2000).
OS: Linux → Windows NT
Yeah, this is a tough bug. I am looking at this.
target_milestone to mozilla1.0 to match same keyword
Target Milestone: mozilla0.9.9 → mozilla1.0
*** Bug 108601 has been marked as a duplicate of this bug. ***
Transfering keywords from duped bug 108601. Also updating summary with topcrash information and trasfering 108601's block bug. The url in this bug consistently crashes for me when I try to load the page and try closing the window: Incident ID 4877218 Stack Signature jvm.dll + 0x22e61 (0x6d442e61) 695fe72d Trigger Time 2002-04-05 17:13:56 Email Address jpatel@netscape.com URL visited http://www.highscore.de/mozilla/getwindow.html Build ID 2002040210 Product ID MozillaTrunk Platform Operating System Win32 Module Trigger Reason Access violation User Comments closing window after trying to load the page Stack Trace jvm.dll + 0x22e61 (0x6d442e61) jvm.dll + 0x24159 (0x6d444159) jpins32.dll + 0x86cb (0x6d2e86cb) jpins32.dll + 0x38c4 (0x6d2e38c4) nsHTMLExternalObjSH::PostCreate [d:\builds\seamonkey\mozilla\dom\src\base\nsDOMClassInfo.cpp, line 4938] XPCWrappedNative::GetNewOrUsed [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 402] XPCConvert::NativeInterface2JSObject [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcconvert.cpp, line 1061] nsXPConnect::WrapNative [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\nsXPConnect.cpp, line 563] nsDOMClassInfo::WrapNative [d:\builds\seamonkey\mozilla\dom\src\base\nsDOMClassInfo.cpp, line 929] nsArraySH::GetProperty [d:\builds\seamonkey\mozilla\dom\src\base\nsDOMClassInfo.cpp, line 4166] nsNamedArraySH::GetProperty [d:\builds\seamonkey\mozilla\dom\src\base\nsDOMClassInfo.cpp, line 4208] XPC_WN_Helper_GetProperty [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, line 785] js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2448] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2596] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806] js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881] JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3414] nsJSContext::CallEventHandler [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182] nsEventListenerManager::HandleEventSubType [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 1218] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 1893] GlobalWindowImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 697] DocumentViewerImpl::LoadComplete [d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 1420] nsDocShell::EndPageLoad [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 3878] nsWebShell::EndPageLoad [d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 731] nsDocShell::OnStateChange [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 3795] nsDocLoaderImpl::FireOnStateChange [d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 1105] nsDocLoaderImpl::doStopDocumentLoad [d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 744] nsDocLoaderImpl::DocLoaderIsEmpty [d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 642] nsDocLoaderImpl::OnStopRequest [d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 573] nsLoadGroup::RemoveRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 531] PresShell::RemoveDummyLayoutRequest [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6628] PresShell::ProcessReflowCommands [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6407] ReflowEvent::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6191] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1078] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 309] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1434] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1769] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1787] WinMainCRTStartup() KERNEL32.DLL + 0x17d08 (0x77e97d08)
Blocks: 126532
Summary: LiveConnect bugs → LiveConnect bugs - Trunk crash [@ JVM.DLL | jvm.dll - nsHTMLExternalObjSH::PostCreate]
Keywords: topcrash+
ok, Priority to P1.
Priority: -- → P1
Hi Xiaobin: You have reassigned this bug to me some time ago. Do you want me to work with you on this? If so, let me know what I can help, I may have some time next week, hopefully. I need to fix my PC before I can do anything though.
Adding myself to the cc. bug 13614 has been marked duplicate of this one. I added talkback data to bug 13614 if you want to doublecheck. The case with http://www.bradesco.com.br is a top major site problem in Brazil (major bank).
This will be fixed in next release of JRE( 1.4.1).
The reason of this bug is because Mozilla locks the message queue while trying to get Java object, however, Java plugin can not return the java object until the applet is started. If you call liveconnect in the start method, it will post the message to the browser event quque and wait for the browser to process it. However, the message queue is locked now due to get java object call. To fix this bug, we will return a java object even the applet has not been started yet. However, we can not support calling liveconnect from the init() method. So put any liveconnect call into start method if you want to access java object when the page is on loading. And the bug fix will be in next release of JRE (1.4.1) as I mentioned before.
Is there anything that can be done in the browser for exsisting JRE's?
Reassigning it back to Xiaobin per our discussion.
Assignee: margaret.chan → xiaobin.lu
Peter: Unfortunately I don't think we can do something in browser side. And also just as I commented above, if you want to get a java object in the onload function, you must put everything liveconect related in the applet start method, otherwise, deadlock will happen. It does make sense not to support init function because we don't know whether the java object is really ready yet and it may be dangerous to hold a java object when the inti method is still processed.
Fixed in JRE 1.4.1.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 118374 has been marked as a duplicate of this bug. ***
*** Bug 118343 has been marked as a duplicate of this bug. ***
Based on XiaoBin, this should be fixed in jre 1.4.1. Let me try on jre 1.4.1 yes, I just tried on jre 1.4.0_01 on windows 98 branch build: 2002-04-26-08-1.0.0, it still crashes twice. Below are the two stracetraces: Stack Trace #1: nsTimerImpl::~nsTimerImpl [d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp, line 176] nsTimerImpl::`scalar deleting destructor' nsTimerImpl::Release [d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp, line 89] destroyMyEvent [d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp, line 393] PL_DestroyEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 634] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 609] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1078] KERNEL32.DLL + 0x24407 (0xbff94407) 0x00688c16 ----------------------------- Stack Trace #2 0x72617620 map_jsj_thread_to_js_context_impl [d:\builds\seamonkey\mozilla\modules\oji\src\lcglue.cpp, line 157] enter_js_from_java_impl [d:\builds\seamonkey\mozilla\modules\oji\src\lcglue.cpp, line 430] jsj_enter_js [d:\builds\seamonkey\mozilla\js\src\liveconnect\jsj_JSObject.c, line 713] nsCLiveconnect::GetWindow [d:\builds\seamonkey\mozilla\js\src\liveconnect\nsCLiveconnect.cpp, line 571] JPINS32.DLL + 0x9d76 (0x01ad9d76) JPINS32.DLL + 0x9b78 (0x01ad9b78) 0x778b0c24
Xiaobin marked this bug is going to fixed in jre 1.4.1 but jre 1.4.1 still hasn't released yet.
This needs to reopen, since this is going to fix in jre 1.4.1, jre 1.4.1 still hasn't released it yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yes, this is still happening with Mozilla 1.0 RC2 (added M1RC2 to summary)...so we need to wait until the new JRE is released so we can verify if it really fixes this problem.
Summary: LiveConnect bugs - Trunk crash [@ JVM.DLL | jvm.dll - nsHTMLExternalObjSH::PostCreate] → LiveConnect bugs - Trunk M1RC2 crash [@ JVM.DLL | jvm.dll - nsHTMLExternalObjSH::PostCreate]
if you are collecting bugs here is another one with a liveconnect problem.. oninit doesn't work with java-applets... bug 115998
To see why oninit does not work, please see my comment on Apr,10.
Blocks: 143047
Keywords: nsbeta1nsbeta1+
Whiteboard: jpibug, topsite → jpibug, topsite [adt1 RTM]
updating summary line to show this is now a M1RC3 topcrash
Summary: LiveConnect bugs - Trunk M1RC2 crash [@ JVM.DLL | jvm.dll - nsHTMLExternalObjSH::PostCreate] → LiveConnect bugs - Trunk M1RC3 crash [@ JVM.DLL | jvm.dll - nsHTMLExternalObjSH::PostCreate]
Blocks: 145287
Lowering impact to [ADT2 RTM], per ADT triage.
Whiteboard: jpibug, topsite [adt1 RTM] → jpibug, topsite [adt2 RTM]
-> topcrash- by talkback triaging team
Keywords: topcrash+topcrash-
Xiaobin, The applet problem in Bradesco bank is still there. I tested with WinME/N7+Java 1.4.1beta. Do you think that case is the oninit case (the other bug)?
See my comment at Apr 10.
Xiaobin: I interprete that you are saying that it is fixed in 1.4.1 and not anything before, such as 1.4.1beta. Correct?
It should be fixed in 1.4.1FCS.
Fixed in JRE 1.4.1
Status: REOPENED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
Keywords: topcrash-topcrash+
Thanks Xiaobin to fix this bug. Yes,it's fixed in jre 1.4.1 (windows 2000, netscape trunk build: 2002-08-07-08-TRUNK)
Status: RESOLVED → VERIFIED
It also fixed in jre 1.4.1 (windows 2000; netscape branch build: 2002-08-07-08-1.0)
Product: Core → Core Graveyard
Crash Signature: [@ JVM.DLL | jvm.dll - nsHTMLExternalObjSH::PostCreate]
You need to log in before you can comment on or make changes to this bug.