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)
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
Reporter | ||
Comment 2•24 years ago
|
||
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>
Assignee | ||
Comment 3•24 years ago
|
||
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
Assignee | ||
Comment 4•24 years ago
|
||
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
Reporter | ||
Comment 5•24 years ago
|
||
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!
Reporter | ||
Comment 7•24 years ago
|
||
Er, that bug 4479764 does not exist.
Assignee | ||
Comment 8•24 years ago
|
||
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.
Reporter | ||
Comment 9•24 years ago
|
||
Umm, is this bug being worked on?
Comment 10•23 years ago
|
||
SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)
QA Contact: shrir → pmac
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•23 years ago
|
||
This is another bug caused by lazy loading fix.
Assignee | ||
Comment 13•23 years ago
|
||
It is a Java Plugin bug. Some class are missing in Java Plugin side. Will
contact Stanley Ho to resolve this!
Assignee | ||
Comment 14•23 years ago
|
||
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.
Reporter | ||
Comment 15•23 years ago
|
||
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.
Assignee | ||
Comment 16•23 years ago
|
||
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.
Assignee | ||
Comment 17•23 years ago
|
||
The first part (no onload) has been fixed in Merlin-beta2 build.
Assignee | ||
Comment 18•23 years ago
|
||
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()
Reporter | ||
Comment 19•23 years ago
|
||
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.
Assignee | ||
Comment 20•23 years ago
|
||
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.
Reporter | ||
Comment 21•23 years ago
|
||
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.
Comment 22•23 years ago
|
||
Couldn't reproduce this bug on Redhat 6.2 and jre 1.4.
Mozilla doesn't crash: browser hangs.
Assignee | ||
Comment 23•23 years ago
|
||
Yes, this is a bug of JPI. We are working on it to get it resolved.
Reporter | ||
Comment 24•23 years ago
|
||
Is bug 100151 a duplicate of this one?
Reporter | ||
Comment 25•23 years ago
|
||
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?
Assignee | ||
Comment 26•23 years ago
|
||
Take a look at it soon!
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.6
Comment 27•23 years ago
|
||
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.
Comment 28•23 years ago
|
||
0.9.6 is out the door.
Reporter | ||
Comment 29•23 years ago
|
||
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.
Comment 30•23 years ago
|
||
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?
Assignee | ||
Comment 31•23 years ago
|
||
Reassign this to Margaret!
Assignee: xiaobin.lu → mtchan
Status: ASSIGNED → NEW
Comment 32•23 years ago
|
||
Moving the Milestone and adding keyword mozilla1.0.
Keywords: mozilla1.0
Target Milestone: mozilla0.9.6 → mozilla0.9.9
Comment 33•23 years ago
|
||
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.
Comment 34•23 years ago
|
||
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).
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Comment 37•23 years ago
|
||
Xiaobin, since this is a JPI bug, any updates on the fix of this bug yet?
Comment 38•23 years ago
|
||
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
Assignee | ||
Comment 39•23 years ago
|
||
Yeah, this is a tough bug. I am looking at this.
Comment 40•23 years ago
|
||
target_milestone to mozilla1.0 to match same keyword
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 41•23 years ago
|
||
*** Bug 108601 has been marked as a duplicate of this bug. ***
Comment 42•23 years ago
|
||
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)
Comment 44•23 years ago
|
||
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.
Comment 45•23 years ago
|
||
Note: This bug also affects https://mediacenter.etrade.com
See http://bugzilla.mozilla.org/show_bug.cgi?id=126532
Whiteboard: jpibug → jpibug, topsite
Comment 46•23 years ago
|
||
http://bugscape.mcom.com/show_bug.cgi?id=13614 is a dup of this bug.
testcase: http://www.bradesco.com.br
Comment 47•23 years ago
|
||
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).
Assignee | ||
Updated•23 years ago
|
Assignee | ||
Comment 48•23 years ago
|
||
This will be fixed in next release of JRE( 1.4.1).
Assignee | ||
Comment 49•23 years ago
|
||
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.
Comment 50•23 years ago
|
||
Is there anything that can be done in the browser for exsisting JRE's?
Comment 51•23 years ago
|
||
Reassigning it back to Xiaobin per our discussion.
Assignee: margaret.chan → xiaobin.lu
Assignee | ||
Comment 52•23 years ago
|
||
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.
Assignee | ||
Comment 53•23 years ago
|
||
Fixed in JRE 1.4.1.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 54•23 years ago
|
||
*** Bug 118374 has been marked as a duplicate of this bug. ***
Comment 55•23 years ago
|
||
*** Bug 118343 has been marked as a duplicate of this bug. ***
Comment 56•23 years ago
|
||
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
Comment 57•23 years ago
|
||
Xiaobin marked this bug is going to fixed in jre 1.4.1 but jre 1.4.1 still
hasn't released yet.
Comment 58•23 years ago
|
||
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 → ---
Comment 59•23 years ago
|
||
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]
Comment 60•23 years ago
|
||
if you are collecting bugs here is another one with a liveconnect problem..
oninit doesn't work with java-applets...
bug 115998
Assignee | ||
Comment 61•23 years ago
|
||
To see why oninit does not work, please see my comment on Apr,10.
Updated•23 years ago
|
Comment 62•23 years ago
|
||
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]
Comment 63•23 years ago
|
||
Lowering impact to [ADT2 RTM], per ADT triage.
Whiteboard: jpibug, topsite [adt1 RTM] → jpibug, topsite [adt2 RTM]
Comment 64•23 years ago
|
||
-> topcrash- by talkback triaging team
Comment 65•23 years ago
|
||
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)?
Assignee | ||
Comment 66•23 years ago
|
||
See my comment at Apr 10.
Comment 67•23 years ago
|
||
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?
Assignee | ||
Comment 68•23 years ago
|
||
It should be fixed in 1.4.1FCS.
Assignee | ||
Comment 69•22 years ago
|
||
Fixed in JRE 1.4.1
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
Comment 70•22 years ago
|
||
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
Comment 71•22 years ago
|
||
It also fixed in jre 1.4.1 (windows 2000; netscape branch build:
2002-08-07-08-1.0)
Updated•14 years ago
|
Crash Signature: [@ JVM.DLL | jvm.dll - nsHTMLExternalObjSH::PostCreate]
You need to log in
before you can comment on or make changes to this bug.
Description
•