77600 - Java to JavaScript does not work [REQUESTOR: us (Xiaobin filed the bug)]

Status: RESOLVED INCOMPLETE

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

Description

[Xiaobin Lu]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
BuildID:    

 Liveconnect does not work now.

Reproducible: Always
Steps to Reproduce:
1. Lauch the testcase, click the button
2. Look at the command line:
   Total weirdness:   No JSJavaVM wrapper ever created for JavaVM 0x013bdb00


Actual Results:    Actually an alert box should pop up.

Expected Results:    Nothing happens!

  I suspect that the lazy loading fix might cause this problem.

Comment 1

[Xiaobin Lu]

Attachment: The testcase

Comment 2

[Phil Schwartau]

On the theory that lazy loading may be involved, reassigning to Patrick - 

Comment 3

[Patrick C. Beard]

Please reattach the test case, you used the wrong MIME encoding (should be binary 
not text).

Comment 4

[Xiaobin Lu]

  Patrick:
    Please give it a suffix like "*.zip" when you download the testcase. It 
works for me and I attached it using text/plain. Let me know if you can not get 
it. 

Comment 5

[Patrick C. Beard]

I find that with the MRJ plugin, this test case works except for the call to 
document.write(), which hangs. If I comment out that call, the test case works. 
On Linux, I get a crash.

Comment 6

[Patrick C. Beard]

Here's the error I get:

#
# HotSpot Virtual Machine Error, Unexpected Signal 11
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 4F533F4C494E55580E43505005BC
#
# Problematic Thread: prio=1 tid=0x80bb808 nid=0xf21 runnable 
#

The hang on document.write() looks like some kind of a deadlock.

Comment 7

[Patrick C. Beard]

I need more information to diagnose this problem. I can investigate the 
document.write() problem, but I don't know what's going on with Linux.

Comment 8

[Xiaobin Lu]

Joe:
   Would you like to explain why it crashes in Linux? I have no idea about 
Linux.

Comment 9

[Xiaobin Lu]

Attachment: Make sure the jsj_ConnectJavaVM is called

Comment 10

[Xiaobin Lu]

 Patrick:
    I just found that the reason of this bug is because when we call 
jsj_MapJavaThreadToJSJavaThreadState(js/src/liveconnect/jsj.c) to get the 
jsj_env,actually we first get the jsjava_vm and then use that to get the 
jsj_env.
   The call looks like:
   jsjava_vm = map_java_vm_to_jsjava_vm(java_vm);
   if (!jsjava_vm) {
        *errp = JS_smprintf("Total weirdness:   No JSJavaVM wrapper ever 
created "
                            "for JavaVM 0x%08x", java_vm);
        return NULL;
    }
   The return value of map_java_vm_to_jsjava_vm is null, this is why we saw 
the "Total weirdness.....". Looking inside the call of map_java_vm_to_jsjava_vm
(java_vm), the jsjava_vm_list->java_vm is NULL and this is because we delay the 
JVM creation and we need to make sure that jvm is created and also attached to 
the jsjava_vm structure. This is why I added a call to jsj_ConnectToJavaVM to 
make sure that the javavm is really attached to that structure.

  Please review the easy fix and give it a super review so liveconnect can 
resume to work as soon as possible. I will investigate the linux crash soon. 
Thanks!

Comment 11

[Xiaobin Lu]

*** Bug 79331 has been marked as a duplicate of this bug. ***

Comment 12

[Xiaobin Lu]

*** Bug 79873 has been marked as a duplicate of this bug. ***

Comment 13

[Prashant Desale]

Xiaobin Lu, 
could you please update sevearity of the bug also when marking 
duplicates. Bug I reported is BLOCKER for me, so I'm marking this one BLOCKER 
too.
For our automation testing to work, its important to testcase at location 
"http://bubblegum/desale/liveconnect/bug.html" to work. This is same testcase as 
in bug# 79873, which is marked duplicate of this bug.

About testcase here, when I click on it it shows some characters on screen & 
thats all. Could you please tell me how to use this testcase ?
I really want to Java-code & how JSfunction is being called from Java. Just to 
make sure that Fixing Bug# 77600 will fix our problem. I know for sure fixing 
Bug#79873 will fix our problem, but now since you marked to Duplicate of 
bug#77600, we've to rely heavily on this bug.
Changing severity to Blocker.

Comment 14

[Xiaobin Lu]

To use the testcase I posted here, just click the button. The correct behavior 
is to pop up an alert window. However, the browser crashes at this moment. I am 
fixing another bug which this bug heavily depends on, I will check the patch 
into trunk after that problem is fixed. I hope it will be available pretty soon.
It is ok for me to mark as BLOCKED.

Comment 15

[Prashant Desale]

Xiaobin Lu,

Thanks for telling me that.
But you know I just don't see any button on testcase. When I click the link for 
testcase, screen shows only wiered characters like "PK|||||#$%^"

I was wondering if I'm doing something wrong.
If its not too much work for you, Could you please paste Java & JS code used in 
testcase ? 
If not its okay. 
Thanks again. Looking forward to this one to get Fixed as soon as possible.

Comment 16

[Xiaobin Lu]

To see the source, go to 78840

Comment 17

[Patrick C. Beard]

-> 0.9.2

Comment 18

[Xiaobin Lu]

I applied the patch to recent trunk code and after 1 minute, it crashes the 
browser and the error message like:

Document file:///D|/bugs/78840/Java2JS.html loaded successfully
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILAB
LE) [nsIURIContentListener.canHandleContent]"  nsresult: "0x80040111 (NS_ERROR_N
OT_AVAILABLE)"  location: "JS frame :: chrome://navigator/content/nsBrowserConte
ntListener.js :: anonymous :: line 131"  data: no]
************************************************************
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILAB
LE) [nsIURIContentListener.canHandleContent]"  nsresult: "0x80040111 (NS_ERROR_N
OT_AVAILABLE)"  location: "JS frame :: chrome://navigator/content/nsBrowserConte
ntListener.js :: anonymous :: line 131"  data: no]

I assume that uriloader has some change which affects our testcase here. Add 
mscott and sspitzer here.

Scott:
    Do you know what does the error message mean here?

Comment 19

[Scott MacGregor]

alecf owns the bug about the JS exceptions in nsBrowserInstance.js. 

Comment 20

[Xiaobin Lu]

Based on Patrick's email to me:
   The liveconnect was totally dead as a result of the XPConnect DOM landing.

Comment 21

[Alec Flett]

and the exception is totally unrelated. see bug 79232

Comment 22

[Xiaobin Lu]

Thanks, Johnny. With patch for 77600, the liveconnect works now.

Comment 23

[Xiaobin Lu]

Patrick:   
      Please get the two lines fix sr. Thanks!

Comment 24

[drapeau]

Marking as one of the OJI group's hot bugs.

Comment 25

[drapeau]

Updating bug summary to better capture exactly which piece of LiveConnect is not
working.

Comment 26

[Xiaobin Lu]

78840 is pretty much solved in Windows platform. After sr I will remove the 
dependency. 

The main problem of this bug now becomes the Unix platform. Basically the 
problem is Java calls Javascript crashes at Unix platform. So, I suggest Joe 
could take it.

Comment 27

[Xiaobin Lu]

*** Bug 82765 has been marked as a duplicate of this bug. ***

Comment 28

[Patrick C. Beard]

r=beard

Comment 29

[Brendan Eich [:brendan]]

I can sr= the patch, and will now: sr=[e-mail].  Someone else should
give a= -- cc'ing chofmann.

/be

Comment 30

[Xiaobin Lu]

 Thanks, Brendan!

Comment 31

[Christopher Blizzard (:blizzard)]

a=blizzard for the trunk on behalf of drivers

Comment 32

[Xiaobin Lu]

Fix checked in!

Comment 33

[Phil Schwartau]

Xiaobin: I am unable to decompress the testcase at 2001-04-25 14:50 above.
You mentioned to Prashant at 2001-05-10 11:05 that the testcase for bug 78840
contains the source. Is that correct? Can I use the testcase for bug 78840
to verify this bug?

Comment 34

[Xiaobin Lu]

  Yes, you can use testcase for 78840 to verify. But remember, because patch for 
78840 is not checked in, you need to go to an applet page (java.sun.com), then 
open the testcase. 

Comment 35

[Phil Schwartau]

Have to reopen this bug. Using trunk binaries 20010613xx on WinNT, Linux, Mac.
Method: as stated above, using the testcase for bug 78840 to verify this bug.

ON WinNT: 
Testcase works perfectly. When I click the "alert" button, the alert comes up

ON THE MAC:
Before the testcase loads, I get two alertboxes saying: 

           java.lang.ArrayIndexOutOfBoundsException
           0>=0

Then the HTML file loads, but I do not see the applet under the words 
"Java to JS Call Test" in the HTML. No "alert" button is visible to click.
No messages in Java Console.



ON LINUX:

The HTML file loads successfully, I can see the applet.
But when I click on the "alert" button, I CRASH.  Running a Linux 
2001-06-13 debug build under a debugger, I can't get a stack trace:

Program exited with code 0377.
(gdb) bt
No stack


Running a Linux Mozilla binary 20010613xx, I got this in the debug console
just before I crashed: 

Document file:////data/phil/77600/Java2JS.html loaded successfully
#
# HotSpot Virtual Machine Error, Unexpected Signal 11
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 4F533F4C494E55580E43505005BC
#
# Problematic Thread: prio=1 tid=0x84154f0 nid=0x7b24 runnable 
#
INTERNAL ERROR on Browser End: Pipe closed during read? State may be corrupt
System error?:: Success


And then a core dump. The DDD debugger debugged this as follows:

Core was generated by `java_vm '.
Program terminated with signal 6, Aborted.
#0  0x4089458b in ?? ()
(gdb) 

Comment 36

[Phil Schwartau]

Note: I compiled the Java classes on my WinNT box and emailed them
      to myself to obtain them on my Linux and Mac boxes. It is my
      understanding that this should work - 


Note: The patch for 78840 was checked in on 2001-06-11.
      Nevertheless, I tried the testcase as if it hadn't been.
      That is, I visited http://www.java.sun.com/applets first
      and clicked on one of their applets before trying the testcase.

Comment 37

[Xiaobin Lu]

Phil:
    For Linux platform, until 83698 is checked in, this testcase will work. As I 
know, 83698 has already got sr and will be checked in soon. So please test it 
after that bug fix has been checked in.

Comment 38

[Xiaobin Lu]

Phil:
    I should tell you you need to recompile those source file for different 
platforms because Plugin SDK package is different for each platforms. It is not 
the right thing to do to use the class file across the different platforms.

Comment 39

[Patrick C. Beard]

> I should tell you you need to recompile those source file for different 
> platforms because Plugin SDK package is different for each platforms.
> It is not  the right thing to do to use the class file across the different
> platforms.

Umm, that totally contradicts WORA, and is blatantly false. The 
netscape.javascript.JSObject API is the same everywhere. Otherwise, we 
couldn't have applets that run unchanged on each platform.

Comment 40

[Xiaobin Lu]

Why Netscape offer different packages for Plugin SDK? I saw there are three 
versions of PluginSDK.

Comment 41

[Xiaobin Lu]

Patrick:
    Thanks for correcting my mistakes! Now I feel I am stupid :).
   

Comment 42

[edburns]

Tested with Tuesday's trunk on win32.  Still works.

Comment 43

[edburns]

Depends on 83698.  Accepting for Xiaobin.

Comment 44

[Xiaobin Lu]

Phil:
    Please test this under Unix. Thanks!

Comment 45

[Phil Schwartau]

Again, as described earlier in this bug, I am using the testcase
for bug 78840 to verify this bug.

Using nightly binary 2001061508 on Linux: testcase PASSES!
The applet loads successfully, and when I hit the "alert" button,
the alert comes up. I do NOT have to open the Java console first.
I can simply bring up Mozilla from scratch, try the testcase, 
and it works!

On Mac, the testcase is still failing as above (2001-06-13 15:51).

Comment 46

[Prashant Desale]

Thanks a lot Patrick for fixing this one.
I needed this one badly for automation harness & it works perfect on windows 
right now. Nisheeth told me about this one on last thursday.
Thnx for fixing this one.

Comment 47

[Patrick C. Beard]

--> 0.9.3

Comment 48

[Blake Ross]

Missed 0.9.3.

Comment 49

[Xiaobin Lu]

Works in Windows and Unix platform.

Comment 50

[Steve K]

Why is platform set to MacOSX here?  This can't possibly apply to MacOS X
because there doesn't yet exist a carbonized MRJ for MacOSX, right?

Will it get on the testing radar for MacOS9 set this way?

Comment 51

[edburns]

9.x

Comment 52

[Patrick C. Beard]

Moving to 0.9.6...

Comment 53

[Patrick C. Beard]

Comment on attachment 32942 [details] [diff] [review]
Make sure the jsj_ConnectJavaVM is called

This patch was checked in as part of the fix for bug 77247.

Comment 54

[Patrick C. Beard]

Using the testcase as-is, I am observing a crash with the current Mac OS X Java
plugin (http://homepage.mac.com/pcbeard/MRJPluginCarbon-1.0d6.sit). If I move
the call to JSObject.getWindow(this) from the init() method of the applet into
the actionPerformed() method of the listener, the crash goes away.

One theory is that we can't get the DOM object of the applet until the applet
has finished initializing, so we may not be able to fix this bug easily. 

Comment 55

[Patrick C. Beard]

Attachment: Updated test case, including CodeWarrior Pro 5 project to build on Mac.

Updating the test case attachment, because the old one had the wrong MIME type.

Comment 56

[Phil Schwartau]

*** Bug 111654 has been marked as a duplicate of this bug. ***

Comment 57

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 58

[Patrick C. Beard]

May neeed to release note this in LiveConnect documentation. Currently we don't
support calling |JSObject.getWindow()| from within the |init()| method of an
applet, because we likely don't have a reference to the applet to associate with
a plugin instance. There may be a way to work around this in various plugins, by
noting the plugin that is currently initializing an applet, but there may not be
a  generic way to fix this.

Comment 59

[Frankie]

Is the testcase supposed to work in Mach-O?

Mozilla CFM build is dead.

Comment 60

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 61

[Simon Paquet [:sipaq]]

Does not qualify as a blocker.

Comment 62

[Bob Clary [:bc] (inactive)]

-> default assignee for old netscape assigned bugs.

Comment 63

[jimmy phillips]

(In reply to comment #10)
>  Patrick:
>     I just found that the reason of this bug is because when we call 
> jsj_MapJavaThreadToJSJavaThreadState(js/src/liveconnect/jsj.c) to get the 
> jsj_env,actually we first get the jsjava_vm and then use that to get the 
> jsj_env.
>    The call looks like:
>    jsjava_vm = map_java_vm_to_jsjava_vm(java_vm);
>    if (!jsjava_vm) {
>         *errp = JS_smprintf("Total weirdness:   No JSJavaVM wrapper ever 
> created "
>                             "for JavaVM 0x%08x", java_vm);
>         return NULL;
>     }
>    The return value of map_java_vm_to_jsjava_vm is null, this is why we saw 
> the "Total weirdness.....". Looking inside the call of map_java_vm_to_jsjava_vm
> (java_vm), the jsjava_vm_list->java_vm is NULL and this is because we delay the 
> JVM creation and we need to make sure that jvm is created and also attached to 
> the jsjava_vm structure. This is why I added a call to jsj_ConnectToJavaVM to 
> make sure that the javavm is really attached to that structure.
>   Please review the easy fix and give it a super review so liveconnect can 
> resume to work as soon as possible. I will investigate the linux crash soon. 
> Thanks!

Comment 64

[Nagy Zoltan]

i've checked the testcase:

the problem is not present anymore, the alert box won't appear,
i recompiled the source and added some extra logging.

tested with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Comment 65

[Benjamin Smedberg]

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".