Closed Bug 90571 Opened 23 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: 22 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: 22 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.