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

RESOLVED INCOMPLETE

Status

Core Graveyard
Java: Live Connect
RESOLVED INCOMPLETE
18 years ago
7 years ago

People

(Reporter: Xiaobin Lu, Unassigned)

Tracking

Trunk
PowerPC
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [oji_escalation])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Created attachment 32196 [details]
The testcase

Comment 2

18 years ago
On the theory that lazy loading may be involved, reassigning to Patrick - 
Assignee: rogerl → beard
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

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

Comment 4

18 years ago
  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

18 years ago
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

18 years ago
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.

Updated

18 years ago
Target Milestone: --- → mozilla0.9.1

Comment 7

18 years ago
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.
(Reporter)

Comment 8

18 years ago
Joe:
   Would you like to explain why it crashes in Linux? I have no idea about 
Linux.
(Reporter)

Comment 9

18 years ago
Created attachment 32942 [details] [diff] [review]
Make sure the jsj_ConnectJavaVM is called
(Reporter)

Comment 10

18 years ago
 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!
(Reporter)

Comment 11

17 years ago
*** Bug 79331 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 12

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

Comment 13

17 years ago
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.
Severity: major → blocker
(Reporter)

Comment 14

17 years ago
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

17 years ago
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.

(Reporter)

Comment 16

17 years ago
To see the source, go to 78840

Updated

17 years ago
Depends on: 78840

Comment 17

17 years ago
-> 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
(Reporter)

Comment 18

17 years ago
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

17 years ago
alecf owns the bug about the JS exceptions in nsBrowserInstance.js. 
(Reporter)

Comment 20

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

Comment 21

17 years ago
and the exception is totally unrelated. see bug 79232
(Reporter)

Comment 22

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

(Reporter)

Comment 23

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

Comment 24

17 years ago
Marking as one of the OJI group's hot bugs.
Whiteboard: [oji_escalation]

Updated

17 years ago
Summary: Liveconnect does not work → Liveconnect does not work [REQUESTOR: us (Xiaobin filed the bug)]

Comment 25

17 years ago
Updating bug summary to better capture exactly which piece of LiveConnect is not
working.
Summary: Liveconnect does not work [REQUESTOR: us (Xiaobin filed the bug)] → Java to JavaScript does not work [REQUESTOR: us (Xiaobin filed the bug)]

Updated

17 years ago
Blocks: 74482

Updated

17 years ago
Blocks: 77194
(Reporter)

Comment 26

17 years ago
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.
(Reporter)

Comment 27

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

Comment 28

17 years ago
r=beard

Updated

17 years ago
Blocks: 83989
I can sr= the patch, and will now: sr=brendan@mozilla.org.  Someone else should
give a= -- cc'ing chofmann.

/be
(Reporter)

Comment 30

17 years ago
 Thanks, Brendan!
a=blizzard for the trunk on behalf of drivers
(Reporter)

Comment 32

17 years ago
Fix checked in!
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 33

17 years ago
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?
(Reporter)

Comment 34

17 years ago
  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

17 years ago
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) 

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 36

17 years ago
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.
(Reporter)

Comment 37

17 years ago
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.
(Reporter)

Comment 38

17 years ago
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

17 years ago
> 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.
(Reporter)

Comment 40

17 years ago
Why Netscape offer different packages for Plugin SDK? I saw there are three 
versions of PluginSDK.
(Reporter)

Comment 41

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

Comment 42

17 years ago
Tested with Tuesday's trunk on win32.  Still works.

Comment 43

17 years ago
Depends on 83698.  Accepting for Xiaobin.
Status: REOPENED → ASSIGNED
Depends on: 83698
(Reporter)

Comment 44

17 years ago
Phil:
    Please test this under Unix. Thanks!

Comment 45

17 years ago
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

17 years ago
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

17 years ago
--> 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 48

17 years ago
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Reporter)

Comment 49

17 years ago
Works in Windows and Unix platform.
OS: All → MacOS X
Hardware: All → Macintosh

Comment 50

17 years ago
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?
(Reporter)

Updated

17 years ago
OS: MacOS X → Mac System 8.0

Comment 51

17 years ago
9.x
OS: Mac System 8.0 → Mac System 9.x

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 52

17 years ago
Moving to 0.9.6...
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 53

17 years ago
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.
Attachment #32942 - Attachment is obsolete: true

Updated

17 years ago
Target Milestone: mozilla0.9.6 → mozilla1.0

Comment 54

17 years ago
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

17 years ago
Created attachment 57969 [details]
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.
Attachment #32196 - Attachment is obsolete: true

Comment 56

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

Comment 57

17 years ago
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)
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 58

17 years ago
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.
Target Milestone: mozilla1.0.1 → Future

Updated

17 years ago
Blocks: 82394

Comment 59

16 years ago
Is the testcase supposed to work in Mach-O?

Mozilla CFM build is dead.
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".

Updated

15 years ago
OS: Mac System 9.x → MacOS X
Does not qualify as a blocker.
Severity: blocker → normal

Comment 62

12 years ago
-> default assignee for old netscape assigned bugs.
Assignee: beard → live-connect
Status: ASSIGNED → NEW
Target Milestone: Future → ---

Comment 63

10 years ago
(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

10 years ago
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

Updated

8 years ago
Component: Java: Live Connect → Java: Live Connect
Product: Core → Core Graveyard

Comment 65

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: NEW → RESOLVED
Last Resolved: 17 years ago7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.