200372 - Error calling Java functions from Javascript (is not a function)

Status: RESOLVED DUPLICATE of bug 115998

(Core Graveyard :: Java: Live Connect, defect)

Description

[William Huang]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Build Identifier: Mozilla/1.4a

The following bit of HTML code works with Java 1.4 plugin on either IE or NS. I 
used HTMLConverter to generate the Code for the Applet.  Javascript can't call 
the Java Applet methods. I get the following message in the Javascript 
console:  document.XpPrint.listPrinters is not a function. 

The Javascript function I am using is:
document.XpPrint.listPrinters(); while I do have the function listPrinters in 
my XpPrint.java class within STestPrint.jar

In the HTML code, I have

<!--"CONVERTED_APPLET"-->
<!-- HTML CONVERTER -->
<SCRIPT LANGUAGE="JavaScript"><!--
    var _info = navigator.userAgent; 
    var _ns = false; 
    var _ns6 = false;
    var _ie = (_info.indexOf("MSIE") > 0 && _info.indexOf("Win") > 0 && 
_info.indexOf("Windows 3.1") < 0);
//--></SCRIPT>
    <COMMENT>
        <SCRIPT LANGUAGE="JavaScript1.1"><!--
        var _ns = (navigator.appName.indexOf("Netscape") >= 0 && ((_info.indexOf
("Win") > 0 && _info.indexOf("Win16") < 0 && java.lang.System.getProperty
("os.version").indexOf("3.5") < 0) || (_info.indexOf("Sun") > 0) || 
(_info.indexOf("Linux") > 0) || (_info.indexOf("AIX") > 0) || (_info.indexOf
("OS/2") > 0) || (_info.indexOf("IRIX") > 0)));
        var _ns6 = ((_ns == true) && (_info.indexOf("Mozilla/5") >= 0));
//--></SCRIPT>
    </COMMENT>

<SCRIPT LANGUAGE="JavaScript"><!--
    if (_ie == true) document.writeln('<OBJECT classid="clsid:8AD9C840-044E-
11D1-B3E9-00805F499D93" WIDTH = 1 HEIGHT = 1 NAME = "XpPrint" 
codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4_1_01-windows-
i586.cab#Version=1,4,1,1"><NOEMBED><XMP>');
    else if (_ns == true && _ns6 == false) document.writeln('<EMBED 
type="application/x-java-applet;version=1.4.1_01" CODE = "XpPrint.class" 
ARCHIVE = "STestPrint.jar" NAME = "XpPrint" WIDTH = 1 HEIGHT = 1 MAYSCRIPT = 
true scriptable=true 
pluginspage="http://java.sun.com/products/plugin/index.html#download"><NOEMBED><
XMP>');
//--></SCRIPT>
<APPLET  CODE = "XpPrint.class" ARCHIVE = "STestPrint.jar" WIDTH = 1 HEIGHT = 1 
NAME = "XpPrint" MAYSCRIPT = true></XMP>
    <PARAM NAME = CODE VALUE = "XpPrint.class" >
    <PARAM NAME = ARCHIVE VALUE = "STestPrint.jar" >
    <PARAM NAME = NAME VALUE = "XpPrint" >
    <PARAM NAME = MAYSCRIPT VALUE = true >
    <PARAM NAME="type" VALUE="application/x-java-applet;version=1.4.1_01">
    <PARAM NAME="scriptable" VALUE="true">
</APPLET>
</NOEMBED>
</EMBED>
</OBJECT>

<!--
<APPLET CODE = "XpPrint.class" ARCHIVE = "STestPrint.jar" WIDTH = 1 HEIGHT = 1 
NAME = "XpPrint" MAYSCRIPT = true>


</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Actual Results:  
document.XpPrint.listPrinters is not a function

Expected Results:  
get printers as String from Java

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Does not seem to be security sensitive, removing flag.

Comment 2

[Sven Sandberg]

Attachment: simpler test case that crashes mozilla 1.4b

All mozilla windows instantly shut down upon loading this page in mozilla 1.4b

Comment 3

[John Hamilton]

If it means anything to the pride of the open-source community...

This bug is quite seriously THE ONLY THING preventing a complete conversion to
Linux desktops that run all of our web-deployed ERP apps through Mozilla.  We
(nor any other users of our ERP software) can not migrate until this bug is fixed.

Please, help us move to Linux!

Regards,
[e-mail]

Comment 4

[Alistair Y. Lewars]

Report, can you please attach a complete working copy of the code that triggers
the bug.  I am unable to reproduce your code in the current version of mozilla
1.5.  The problem you are reporting may well have been fixed already.  Howeve,
it may not.  So, please attache a complete test case of the submitted code.

Thanks. 

Comment 5

[Scott Morris]

Attachment: Test Case that works properly, calls applet directly

Comment 6

[Scott Morris]

Attachment: Test case that fails, applet method called by variable

Comment 7

[Scott Morris]

We are able to replicate this as well on Firefox 0.8 on Linux only. It works
fine using Firefox on Windows and using IE on Windows. The issue seems to come
up when the java applet is contained within a separate frame from the main
content page. If the main content page javacript calls the applet method
directly (parent.applet_frame.APPLETNAME.testFunction), it works properly (see
attachment "test_case_working"). The starting page is main.html 

However, if a reference to the applet is stored in a variable, and the content
page calls the applet method via the variable
(parent.applet_frame.VARIABLE_POINTING_TO_APPLET.testFunction), the javascript
error appears indicating that it is not a function (see attachment
"test_case_failure"). The starting page is main.html

Comment 8

[chris hofmann]

it would be very good if we could get this one figure out and fixed by 1.7.

Comment 9

[Brendan Eich [:brendan]]

This bug is surely misassigned.  It also seems like a dup of bug 115998,
although from the excellent test cases attached, I see something strange:

one you sample the document.API object reference in the failing case, you've
poisoned the well such that even later references to document.API.testFunction
find no such function -- in addition to theAPI.testFunction finding n.s.p.

This suggests a workaround, which I am attaching next.  I believe jst is hacking
up a patch for bug 115998, which *should* fix this bug too -- we'll try to get
that into 1.7 final.

I think this bug should be in a different component from Java-implemented
Plugins, but I'll let kyle, jst, or asa fix that.  I'm reassigning to kyle for
now -- hope that's ok.

/be

Comment 10

[Brendan Eich [:brendan]]

Attachment: applet.html modified with a workaround

Can folks suffering this bug please try the workaround shown here and report
back? Thanks.

/be

Comment 11

[Johnny Stenback (:jst)]

Attachment: Test applet from the earlier testcases.

Comment 12

[Johnny Stenback (:jst)]

Attachment: Applet frame for testcase

Comment 13

[Johnny Stenback (:jst)]

Attachment: Form frame for testcase

Comment 14

[Johnny Stenback (:jst)]

Attachment: Main testcase file

Comment 15

[Johnny Stenback (:jst)]

Comment on attachment 144087 [details]
Test applet from the earlier testcases.

Argh, this didn't work :-( Attaching a new zip file.

Comment 16

[Johnny Stenback (:jst)]

Attachment: Updated testcase (zip file)

Comment 17

[Johnny Stenback (:jst)]

Sorry for the attachment mess.

I've been poking around with this testcase and there appear to be more problem
here than meets the eye.

The latest attachment (attachment 144091 [details]) shows part of what's going on here.
The first time this testcase is loaded (i.e. before any other java has been
executed) this shows that the first call through java in this testcase never
returns, ever. The testcase has code that shows the current status in a "status"
input, it shows if it's in the call on the applet or if it's done, the first
time you call through java, the status is changed to "Entering...", and nothing
happens after that. The second time a call is made, it goes through, and status
is changed to "Entering...", and back to "Done.".

Looks like the JVM is nesting a window message loop, and it just keep spinning
it, probably until it it's killed by the window going away, or somesuch. This
can be seen from stacktraces such as:

  gklayout.dll!GlobalWindowImpl::HandleDOMEvent() Line 901
  ...
  gkwidget.dll!nsWindow::ProcessMessage() Line 4017 + 0x1
  gkwidget.dll!nsWindow::WindowProc() Line 1346 + 0x1
  user32.dll!77d43a50()
  user32.dll!77d43b1f()
  user32.dll!77d43d79()
  user32.dll!77d44374()
  045f8392()
  045f2c03()
  045f2c03()
  045f00f4()
  jvm.dll!08070c8a()
  jvm.dll!080aab6d()
  jvm.dll!08070b97()
  jvm.dll!08076901()
  jvm.dll!08076ec8()
  jpinsp.dll!6d365b3b()
  jpinsp.dll!6d363b22()
  jpins7.dll!6d353e46()
  oji.dll!ProxyJNIEnv::InvokeMethod() Line 573 + 0x2
  oji.dll!ProxyJNIEnv::InvokeMethod() Line 582 + 0x1
  oji.dll!ProxyJNIEnv::CallObjectMethod() Line 643 + 0x21
  jsj3250.dll!jsj_ReflectJavaMethods() Line 562 + 0x1
  jsj3250.dll!reflect_java_methods_and_fields() Line 553 + 0x15
  jsj3250.dll!jsj_GetClassInstanceMembers() Line 601 + 0x13
  jsj3250.dll!jsj_LookupJavaMemberDescriptorById() Line 697 + 0x11
  jsj3250.dll!lookup_member_by_id() Line 512 + 0x15
  jsj3250.dll!JavaObject_lookupProperty() Line 820 + 0x25
  js3250.dll!_js_LookupProperty() Line 2482 + 0x29
  js3250.dll!js_GetProperty() Line 2594 + 0x23
  js3250.dll!js_Interpret() Line 2792 + 0x6
  js3250.dll!js_Invoke() Line 958
  js3250.dll!js_InternalInvoke() Line 1035 + 0x14
  js3250.dll!JS_CallFunctionValue() Line 3589 + 0x1
  gklayout.dll!nsJSContext::CallEventHandler() Line 1293 + 0x21
  gklayout.dll!nsJSEventListener::HandleEvent() Line 175 + 0x2
  gklayout.dll!nsEventListenerManager::HandleEventSubType() Line 1434 + 0x14
  gklayout.dll!nsEventListenerManager::HandleEvent() Line 1529
  gklayout.dll!nsGenericElement::HandleDOMEvent() Line 1959
  gklayout.dll!nsHTMLInputElement::HandleDOMEvent() Line 1396 + 0x1
|-- Initial click on the button, this event handler never returns
  ...
  gkwidget.dll!nsWindow::ProcessMessage() Line 4017 + 0x1
  gkwidget.dll!nsWindow::WindowProc() Line 1346 + 0x1
  user32.dll!77d43a50()
  user32.dll!77d43b1f()
  user32.dll!77d43d79()
  user32.dll!77d43ddf()
  appshell.dll!nsAppShellService::Run() Line 524
  mozilla.exe!main1() Line 1298 + 0x20

This is from moving the mouse in the window after clicking on the testFunction()
button the first time, this shows that the event handler that made the initial
call to testFunction() is still going (towards the bottom of the stack), but the
JVM/Java plugin didn't return to the event handler yet, and it won't do that, at
least not as long as the applet is loaded.

This alone is obviously a big problem, one that should be fixed in the Java
plugin. I don't think there's anything that can be done about this in Mozilla.

Playing with this testcase also ends asserting in the JS engine in debug builds,
brendan's got more on what's going on there.

As for the 'testFunction is not a function' error I haven't seen on WinXP, maybe
that's something that's only visible on Linux?

Comment 18

[Johnny Stenback (:jst)]

Looks like the above always happens on WinXP, regardless of timeouts or whatever
before accessing the applet the first time. The first call through the applet
gets stuck.

Comment 19

[Johnny Stenback (:jst)]

Kyle, or anyone, is there any callback of anything like that in the java plugin
that would tell mozilla when an applet is fully initialized, i.e. everything is
downloaded and it's ready to go?

Comment 20

[Kyle Yuan]

Changing component to Liveconnet and ccing Xiaobin.

Comment 21

[Kyle Yuan]

Some URLs for accessing those testcases remotely:

Test Case that works properly, calls applet directly
jar:http://bugzilla.mozilla.org/attachment.cgi?id=143543&action=view!/main.html

Test case that fails, applet method called by variable
jar:http://bugzilla.mozilla.org/attachment.cgi?id=143544&action=view!/main.html

Updated testcase (zip file)
jar:http://bugzilla.mozilla.org/attachment.cgi?id=144091&action=view!/main.html

Comment 22

[Kyle Yuan]

Actually, this is a dupe of 115998, and it was fixed in jre1.5.

The problem could be tracked from
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsDOMClassInfo.cpp#6020

If using jre1.4.2 or earlier on Linux, appletObject will be NULL when try to get
it in the onload handler. But in jre1.5.0, GetJavaObject won't return until
applet gets initialized.

re comment 18, the first call to java does not get stuck, it just very very
slow, especially in debug mode. It may take a couple of minutes to complete the
first call if you run mozilla in Visual Studio.

re comment 17, I do not know exactly how java plugin works with jvm, but the
stack shows me that it is still in the reflection stage - reflect hundreds java
methods to js methods. it is also why the first call is very slow.

re comment 19, now we don't need a finish loading notification of applet,
because in new jre1.5 implementation, it guarantee that the GetJavaObject will
return after applet's initialization. 

*** This bug has been marked as a duplicate of 115998 ***

Comment 23

[Brendan Eich [:brendan]]

> re comment 19, now we don't need a finish loading notification of applet,
> because in new jre1.5 implementation, it guarantee that the GetJavaObject will
> return after applet's initialization. 

Kyle, how long does that call take to return in the new jvm?

/be

Comment 24

[Kyle Yuan]

(In reply to comment #23)
> Kyle, how long does that call take to return in the new jvm?
> 
> /be

It depends on how big the applet is. It wont impact the performance, because the
applet always needs some time to be started. New jvm just makes it started
earlier (before we try to use it).

Comment 25

[Asa Dotzler [:asa]]

Should this blocking nomination be moved to bug 115998?

Comment 26

[Kyle Yuan]

No, there is nothing to do in mozilla. It's a java plugin bug and has been fixed
in next release of JRE. 
In theory we can also close bug 115998, but I think it's better to keep it
opened until next JRE released.