301494 - Liveconnect don't work with recursive calls

(Reporter)

Description

•

13 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6


The applet calls a javascript function (init) that calls a applet
method (init_) and, finally, this method calls another javascript
function (alertFromApplet) in a sequence.

Applet code (firefox/FirefoxTest.java):

package firefox;

import java.awt.*;

import netscape.javascript.*;

public class FirefoxTest extends java.applet.Applet
{
  private int build = 5;

   public void init()
   {
       System.out.println("build: "+build);
   }

   public void start()
   {
      // this call javascript init function
      callJavascript(null, "init");
   }
   /**
    * Called by javascript.
    */
   public void init_()
   {
      System.out.println("javascript call me!");
      String[] param = { new Integer(build).toString()};
      callJavascript(param , "alertFromApplet");
   }

   /**
    * Call a javascript function.
    */
   private void callJavascript(final String[] args, final String function)
   {
      try
      {
         JSObject win = JSObject.getWindow(this);
         win.call(function, args);
      }
      catch(Exception E)
      {
         E.printStackTrace();
      }
   }

   public void paint(Graphics g)
   {
      g.drawString("Testing liveconnect...", 0, 12);
   }
}

Javascript code (ff.js):


function init()
{
  alert("init");
  document.ff.init_();
}

function alertFromApplet(n)
{
  alert('applet call me: ' + n +'!');
}

html code (firefox-test.html):

<html>
   <head>
   <title></title>
   <script language=JavaScript src='ff.js'></script>
   </head>
   <body>
   <APPLET codebase="." code="firefox.FirefoxTest" archive="firefox-test.jar"
   name="ff" id="ff" width="105" height="35" MAYSCRIPT>
   </APPLET>
   </body>
</html>

This works fine on IE, but don't work in (at least in 1.0.5 and 1.0.6)
Firefox. I've tested now in Safe Mode and it works fine. I disabled
the adblock extension for test and it worked too. I cannot say if are
the extension affecting the behavior or if are the changes at API.

I've tested in:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.9)
Gecko/20050711 Firefox/1.0.5

and

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6

I have another machine with 1.0.3 and there don't work too.

The JVM is:

Java Plug-in 1.5.0_02
Using JRE version 1.5.0_02 Java HotSpot(TM) Client VM

Works fine with IE 6 with MS-JVM and with Sun Plug-in.


Reproducible: Always

Steps to Reproduce:
1. Open the url http://www.q10.com.br/teste/firefox-test.html
2. This will pop up a javascript alert window, click on ok
3. Next it should pop up another javascript alert window with text: "applet call me"
Actual Results:  

Step 3 never work. Sometimes it even crash Firefox after some seconds and
sometimes it crash on page reload. 
The call made in javascript function init (document.ff.init_();) never return.

Expected Results:  
Step 3 may work and Firefox may never crash.

I think this is related to bug #294833.

Emerson

(Reporter)

Comment 1

•

13 years ago

Tested on "Deer Park Alpha 2" (Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.8b4) Gecko/20050720 Firefox/1.0+) and the behaviour was the
same.

Emerson

(Reporter)

Comment 2

•

13 years ago

Talkback ID to this bug when I did a page reload with a clean profile:

TB7797939G

On page reload the Firefox 1.0.6 simply crashed.

Emerson

(Reporter)

Comment 3

•

13 years ago

Sorry for another...

I do a test with Deer Park Alpha2 and it crashed too. The talkback ID is:

TB7798152E

timeless

Comment 4

•

13 years ago

Incident ID: 7797939
Stack Signature	0xb7efd74b 3800c6b3
Product ID	Firefox10
Build ID	2005071605
Trigger Time	2005-07-25 13:24:53.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	
URL visited	http://www.q10.com.br/teste/firefox-test.html
User Comments	Crashed on page reload. This is related to bug #301494
Since Last Crash	682 sec
Total Uptime	35295 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0xb7efd74b
jpioji.dll + 0x4867 (0x6d444867)
jpinscp.dll + 0x3956 (0x6d423956)
USER32.dll + 0x2a420 (0x77e3a420)
USER32.dll + 0x6b41 (0x77e16b41)
USER32.dll + 0x6b64 (0x77e16b64)
PluginWndProc 
[c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/modules/plugin/base/src/nsPluginNativeWindowWin.cpp,
line 266]
USER32.dll + 0x2a420 (0x77e3a420)
USER32.dll + 0x4605 (0x77e14605)
USER32.dll + 0xa7ba (0x77e1a7ba)
nsAppShellService::Run 
[c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
KERNEL32.DLL + 0x2893d (0x7c59893d)

Incident ID: 7798152
Stack Signature	GetSCCRootFor 9b732369
Product ID	FirefoxTrunk
Build ID	2005072006
Trigger Time	2005-07-25 13:31:22.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	firefox.exe + (0013c9d0)
URL visited	http://www.q10.com.br/teste/firefox-test.html
User Comments	Testing with Deer Park Alpha2 This crash is related to bug #301494
Since Last Crash	2074 sec
Total Uptime	2074 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 4415
Stack Trace 	
GetSCCRootFor 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 4415]
ClassifyWrapper 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 4642]
nsDOMClassInfo::BeginGCMark 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 4680]
nsDOMClassInfo::MarkReachablePreservedWrappers 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 4594]
nsNodeSH::Mark 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 5579]
XPC_WN_Helper_Mark 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 938]
js_Mark  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsobj.c,
line 4074]
MarkGCThing 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1138]
js_MarkGCThing 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1438]
MarkGCThing 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1138]
js_MarkGCThing 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1438]
XPC_WN_Shared_Mark 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 709]
MarkGCThing 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1138]
MarkGCThing 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1225]
MarkGCThing 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1225]
MarkGCThing 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1225]
js_MarkGCThing 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1438]
js_GC  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c,
line 1694]
js_ForceGC 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1502]
nsAppStartup::Run 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 146]
main 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 61]
KERNEL32.DLL + 0x2893d (0x7c59893d)

Severity: major → critical

Keywords: crash

Emerson

(Reporter)

Comment 5

•

13 years ago

Hello,

Just like bug #294833, even never confirmed, seems that with Deer Park Alpha2
(Mozilla/5.0 (Windows; U;
Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050816 Firefox/1.0+) this bug was fixed.

A colateral effect is that the page test (and any other with an applet) is
loading very slowly.

Emerson

(Reporter)

Comment 6

•

13 years ago

Ok, something gets wrong and (like bug 294833) this test applet  doesn't work again (since the fix
worked on Deer Park Alpha2, the code was not included at release version?). But, it
doesn't crash FF anymore, so I'm downgrading the severity...

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111
Firefox/1.5
Java Plug-in 1.5.0_06
Using JRE version 1.5.0_06 Java HotSpot(TM) Client VM

I think this is strongly related to this bug 254285.

Severity: critical → major

Emerson

(Reporter)

Comment 7

•

13 years ago

I've got these two detailed errors on javascript console on new SeaMonkey[1] and JRE 1.5[2]:

Error: [Exception... "'Permission denied to get property XULElement.accessKey' when calling method: [nsIDOMXULLabelElement::accessKey]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "JS frame :: http://www.q10.com.br/teste/ff.js :: init :: line 4"  data: no]
Source File: http://www.q10.com.br/teste/ff.js
Line: 4

Error: [Exception... "'Permission denied to get property XULElement.accessKey' when calling method: [nsIDOMXULLabelElement::accessKey]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "JS frame :: http://www.q10.com.br/teste/ff.js :: alertFromApplet :: line 10"  data: no]
Source File: http://www.q10.com.br/teste/ff.js
Line: 10

But, diferently of Firefox, the test case worked.

[1] Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.1) Gecko/20060130
SeaMonkey/1.0
[2] Java Plug-in 1.5.0_06 Using JRE version 1.5.0_06 Java HotSpot(TM) Client VM

Istvan Fajth

Comment 8

•

10 years ago

Hi!

I've got the same problem with ff2.0.0.16, and java 1.6_10ea using liveconnect, and our applet.

Our applet is not available on the public net till some days, but i'll commit the url after we release our new version. But it behaves like the first example. While the applet init is running, it calls a javascript function, wich calls a public function of the applet object. And on the javascript console i'm getting an error wich says the called applet function isn't exists.

For me it was enough to call the functions, and initialize some textfields after the applet initialization with a javascript call, coming after the applet loading. While the initialization runs, i'm not able to eliminate the javascript call, from my applet, so my site throw a javascript error but at least works well. The interesting thing is that: while the initialization is running, the applet object in javascript isn't null, but it hasn't got its public functions.

I investigating some time to find out what may happen, and when i've tried to do a history back, and forward in the browser (not from code, only click to the arrows in the browser toolbar) i've got that, the applet destroy() function is called, and the aplet is quiting well, but when move forward to the applet's page, the javascript applet object is ponting to the old destroyed applet, while the initialization is running.

Hope it helps, if we released our program and the applet will be available, i'll submit the url. I haven't tested this in ff3 but i plan to do it.

Istvan Fajth

Comment 9

•

10 years ago

Recent new informations about our applet:
the problematic demo is available at http://www.chemaxon.com/marvin/examples/applets/sketch/chemicalterms2.html

In the example our applet fires propertychange events from java to javascript, and the javascript code refresh the textfields based on the applet's public function's return value. In the end of the init function we add the propertychange functionality, and then we fire a propertychange event, which will cause the javascript evaluateChemicalTerms function's run, but the applet object is null, and the javascript function body isn't running. 

When i make a refresh, or a back and forward navigation then i'm getting the  "document.MSketch.evaluateChemicalTerms is not a function" error, and experienced that the applet object points to the previous instance of the applet, and it isn't null, not even if the body's onunload event setting it to null.

I think its a javascript variable caching or applet initialization problem, but i'm not sure, as i'm not sure about that, this is a fox bug. If it is necessary i can give u a simple example or further information about our implementation which is a common and simple way to map propertychange events cause changes in an html document, as i think.

If any information is needed to confirm the bug, please inform me, i'm very interested in at least the cause of the problem, or any workaround, because our example code now is a glorious hack to avoid the problem and get the functionality needed by our users.

Oh and i haven't write that in the previous post, it occurs by us in windows vista and in windows xp either 32 or 64 bit versions, works in a linux environment with Bon Echo, we haven't tested other environments only with the almost well working workaround hack.

Istvan Fajth

Comment 10

•

10 years ago

I've tested it in ff3 too, the default implementation won't work in the 3.0.1 version, but at least the workaround works without errors.

timeless

Updated

•

8 years ago

Component: Java: Live Connect → Java: Live Connect

Product: Core → Core Graveyard

Benjamin Smedberg

Comment 11

•

7 years ago

Firefox code moved from custom Liveconnect code to the NPAPI/NPRuntime bridge a while back. Mass-closing the bugs in the liveconnect component which are likely invalid. If you believe that this bug is still relevant to modern versions of Firefox, please reopen it and move it the "Core" product, component "Plug-Ins".

Status: UNCONFIRMED → RESOLVED

Last Resolved: 7 years ago

Resolution: --- → INCOMPLETE

Bugzilla

Liveconnect don't work with recursive calls

Status

People

(Reporter: emerson.pardo, Unassigned)

Tracking

({crash})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Security

(public)

User Story

Description

Comment 1

Comment 2

Comment 3

Comment 4

Comment 5

Comment 6

Comment 7

Comment 8

Comment 9

Comment 10

Updated

Comment 11