83698 - JavaScript to Java won't work unless open Java console first

Status: VERIFIED FIXED

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

Description

[Joe Chou]

After the fix of 82034, JavaScript to Java communication works OK on Windows.
But on Unix, without opening Java console first, the communication would not
work, and the browser was hung.

To reproduced the problem, first make sure the fix of 82034 is in your build,
then try the test case attached. If open Java console first, then go to the test
page, it will work. But if go to the test page first, and then open Java
console, the browser will be hung. To verify if it work or not, when press the
print button in the test case, a message should be displayed in Java console,
saying that the print was called.

Comment 1

[Joe Chou]

Attachment: A simple test case

Comment 2

[Joe Chou]

Assignd to myself.

Comment 3

[Phil Schwartau]

Let me move this over to the OJI component to match the other bugs
you mentioned above - 

Comment 4

[Joe Chou]

Attachment: Patch to resolve the problem on Unix.

Comment 5

[Joe Chou]

CC Patrick Beard (liveconnect owner) and Chris Karnaze (layout owner), since the
patch changes code in the two modules. Can you review the patch (actually
Patrick drafted the patch), please? With the patch, test on Linux seemed OK now.

Comment 6

[Patrick C. Beard]

r=beard

Comment 7

[Joe Chou]

Patrick, whom should I ask for sr=, any suggestions?

Comment 8

[Patrick C. Beard]

brendan, would you sr?

Comment 9

[Joe Chou]

Brendan, without this fix, Unix JavaScript to Java will not work unless opening
Java console first. Would you sr, please?

Comment 10

[Xiaobin Lu]

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

Comment 11

[edburns]

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

Comment 12

[Joe Chou]

Since this problem also hangs the browser when doing Java to JavaScript
communications, made this a priority 2 bug. The patch also resolves the Java to
JavaScript problem.

Comment 13

[Xiaobin Lu]

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

Comment 14

[John Bandhauer]

I got asked to super review this. Can you please tell me whiy this is only a 
problem in Unix? Is this not a problem on Mac? Does this make initializing the 
the JVM more eager on Unix? Even if it is not *needed* on other platforms, what 
is the reason for not doing it anyway on other platforms?

Comment 15

[Patrick C. Beard]

UNIX OJI plugings communicate with an out of process JVM. Windows and Mac OJI 
plugins are entirely in-process. We discovered that the communication protocol 
doesn't work unless you eagerly create the JNI environment before instantiating 
the OJI plugin.

Comment 16

[Joe Chou]

Patrick, does that mean Mac does not have the problem then? We know Windows does
not.

Comment 17

[John Bandhauer]

sr=jband. Patrick, Thanks for clearing up my questions.

Comment 18

[John Bandhauer]

Joe: Please add a comment in the code where it checks for XP_UNIX that briefly 
explains why that section of code is Unix specific. Just quoting what Patrick 
wrote is fine. It is good to have this stated clearly in the code for future 
maintainers.

Comment 19

[Joe Chou]

I'll do that, and I'll add a new attcchment to reflect that. Thanks, John.

Comment 20

[Joe Chou]

Attachment: Added comments to the patch

Comment 21

[Joe Chou]

Here is some more explanation of the problem, which has been added to the
comments of the patch:
 
The proxy JNI needs to be created by the browser. If it is created by
someone else (e.g., a plugin), the proxy somehow will not work, and break
LiveConnect. Currently, on Unix, when instantiating a Java plugin 
instance (by calling InstantiateEmbededPlugin() next), Java plugin will 
create the proxy JNI if it is not created yet. If that happens, Live-
Connect will be broken. Before lazy start JVM was implemented, since at 
this point the browser already created the proxy JNI buring startup, 
the problem did not happen. But after the lazy start was implemented, 
at this point the proxy JNI was not created yet, so the Java plugin 
created the proxy JNI, and broke liveConnect.
On Windows, Java plugin just lets the browser create the proxy JNI, 
and hence does not have such a problem.

The work-around:
The root cause of the problem is in Java plugin's Unix implementation,
and it should let the browser to create the proxy JNI. A seperate bug 
will be filed against Java plugin. 
Untill the bug is fixed in Java plugin, as a work-around, make sure the 
proxy JNI has been created by the browser here, before plugin gets a 
chance.

Comment 22

[Joe Chou]

Can I get a= from someone, please?

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Why the

+   } else {
+       return rv;
+   }

?  Could this break plugins (#ifdef XP_UNIX) if OJI is not installed?  (Is it
better to just continue if the GetService fails?)  (I would think we might
distribute without OJI in some embedding cases.)  It seems like the other code
that uses nsIJVMManager outside of oji doesn't fail this way if it doesn't exist.

I don't see OJI in
http://lxr.mozilla.org/seamonkey/source/embedding/config/basebrowser-unix .

Comment 24

[Joe Chou]

Attachment: Modified patch to avoid breaking other plugins

Comment 25

[Joe Chou]

Good catch. If a browser does not have Java plugin, but have other embeded
plugins, it will break at the else part. Modified the patch to remove the else
statement. Can I get a= now?

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

a=dbaron for trunk checkin if your reviewer agrees that the change is correct.

Comment 27

[Joe Chou]

Patrick and John, any comments to the change?

Comment 28

[Joe Chou]

Patch has been checked into trunk.

Comment 29

[drapeau]

Noting high-priority status of this bug in Status Whiteboard.

Comment 30

[Joe Chou]

Marked fixed.

Comment 31

[Mike Kaply [:mkaply]]

I'm going to checkin an XP_OS2 for this fix as well.

The OS/2 java plugin is based on the unix java plugin.

Comment 32

[shrirang khanzode]

Liveconnect qa->[e-mail]                                                                      

Comment 33

[Phil Schwartau]

Verified Fixed with Mozilla trunk binary 2001111109 on Linux.

1. I brought up Mozilla
2. I brought up Joe's testcase FIRST.
3. I brought up the Java Console SECOND.
4. Everything worked, and print messages appeared in the Java Console

Comment 34

[Phil Schwartau]

Note: testcase also works with Mozilla trunk 20011113xx on WinNT,
although it seems that this was never an issue on Windows -