Closed Bug 77600 Opened 23 years ago Closed 13 years ago

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

Categories

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

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: xiaobin.lu, Unassigned)

References

Details

(Whiteboard: [oji_escalation])

Attachments

(1 file, 2 obsolete files)

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.
Attached file The testcase (obsolete) —
On the theory that lazy loading may be involved, reassigning to Patrick - 
Assignee: rogerl → beard
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please reattach the test case, you used the wrong MIME encoding (should be binary 
not text).
  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. 
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.
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.
Target Milestone: --- → mozilla0.9.1
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.
Joe:
   Would you like to explain why it crashes in Linux? I have no idea about 
Linux.
 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!
*** Bug 79331 has been marked as a duplicate of this bug. ***
*** Bug 79873 has been marked as a duplicate of this bug. ***
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
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.
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.

To see the source, go to 78840
Depends on: 78840
-> 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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?
alecf owns the bug about the JS exceptions in nsBrowserInstance.js. 
Based on Patrick's email to me:
   The liveconnect was totally dead as a result of the XPConnect DOM landing.
and the exception is totally unrelated. see bug 79232
Thanks, Johnny. With patch for 77600, the liveconnect works now.

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

Marking as one of the OJI group's hot bugs.
Whiteboard: [oji_escalation]
Summary: Liveconnect does not work → Liveconnect does not work [REQUESTOR: us (Xiaobin filed the bug)]
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)]
Blocks: 74482
Blocks: 77194
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.
*** Bug 82765 has been marked as a duplicate of this bug. ***
r=beard
Blocks: 83989
I can sr= the patch, and will now: sr=brendan@mozilla.org.  Someone else should
give a= -- cc'ing chofmann.

/be
 Thanks, Brendan!
a=blizzard for the trunk on behalf of drivers
Fix checked in!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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?
  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. 
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 → ---
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.
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.
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.
> 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.
Why Netscape offer different packages for Plugin SDK? I saw there are three 
versions of PluginSDK.
Patrick:
    Thanks for correcting my mistakes! Now I feel I am stupid :).
   
Tested with Tuesday's trunk on win32.  Still works.
Depends on 83698.  Accepting for Xiaobin.
Status: REOPENED → ASSIGNED
Depends on: 83698
Phil:
    Please test this under Unix. Thanks!
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).
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.
--> 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Works in Windows and Unix platform.
OS: All → MacOS X
Hardware: All → Macintosh
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?
OS: MacOS X → Mac System 8.0
9.x
OS: Mac System 8.0 → Mac System 9.x
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Moving to 0.9.6...
Target Milestone: mozilla0.9.5 → mozilla0.9.6
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
Target Milestone: mozilla0.9.6 → mozilla1.0
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. 
Updating the test case attachment, because the old one had the wrong MIME type.
Attachment #32196 - Attachment is obsolete: true
*** Bug 111654 has been marked as a duplicate of this bug. ***
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
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
Blocks: 82394
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".
OS: Mac System 9.x → MacOS X
Does not qualify as a blocker.
Severity: blocker → normal
-> default assignee for old netscape assigned bugs.
Assignee: beard → live-connect
Status: ASSIGNED → NEW
Target Milestone: Future → ---
(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!

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

Product: Core → Core Graveyard
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
Closed: 23 years ago13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: