Closed Bug 202416 Opened 21 years ago Closed 11 years ago

No Mozilla UNIX browser and Java Plugin fully supports LiveConnect

Categories

(Core Graveyard :: Java: OJI, defect)

Other
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: prentice, Assigned: alfred.peng)

References

()

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

The above link goes to the LiveConnect Java to JS tests which are refered to
below.  All tests are run with the 1.4.1 Plug In and 1.4.1 JVM/JRE.  Also tested
with 1.4.2 JVM and Plug In with same results.

On Red Hat 7.2:

Mozilla 1.2.1:
Locks up on Test # 1, and likely more.

Mozilla 1.3:
Locks up on Tests # 3 and 5.

Mozilla 1.4a:
Locks up on Tests # 7, 8, and 10.


On Solaris:

NN 7.0:
Locks up on Tests # 7 and 8.
Intermittant lock ups on Test #4.

Mozilla 1.2.1:
Did not lock up or crash on any of the tests.  But only displayed the header and
no PASSED values for 2 of the tests.

On HP-UX 11.11:

NN 7.0:
Locks up on Tests # 7 and 8.


On XP:

NN 7.02:
All tests work.

Reproducible: Always

Steps to Reproduce:
1.Browse to
http://www.mozilla.org/quality/browser/front-end/testcases/oji/javatojstests.html
2.Click on every test, etc
3.

Actual Results:  
Listed above in details.

Expected Results:  
It should have displayed the PASSED value for all of the tests and never locked up.

No theme changes were made, so Default theme was used.
No other plug ins were installed.
All relavent Solaris patches were confirmed installed as well as all toolkits
(GTK , etc).
It should be added that we need this functionality to work on a number of
platforms, HP-UX, Solaris, Linux, Windows, AIX, etc.  It's been consistantly
broken on all UNIX related platforms since Mozilla 1.0.
On Solaris:

Mozilla 1.2.1:
Did not lock up or crash on any of the tests.  But only displayed the header and
no PASSED values for 2 of the tests.  I think this may be the correct behavior,
as this is the same as NN 7.02 on XP.

Test #7 displays only the following in bold, as a header:
enum-001 The variable statment

Test #8 displays only the following in bold, as a header:
enum-002 The variable statment

All of the Javascript to Java tests seem to pass for all platforms and all browers.
On the JS to Java Test #10 I get the following errors in my JS Console:

Error: testcases[tc] has no properties
Source File:
http://www.mozilla.org/quality/browser/front-end/testcasts/jstojava/browser.js  
Line: 105

Error: Unable to convert JavaScript value NaN to Java Value of type long
Source File:
http://www.mozilla.org/quality/browser/front-end/testcasts/jstojava/long-003-n.js
Line: 33

This occurs on Mozilla 1.2.1 on Solaris 8 with 1.4.2 JVM/Plug In, and on XP with
NN 7.02 with 1.4.1 JVM/Plug In.
Severity: blocker → major
http://developer.java.sun.com/developer/bugParade/bugs/4837766.html

The above seems to be a very similar defect.  Supposedly fixed in 1.4.2 JRE/OJI.
The 1.4.2 OJI/JRE is not available for all platforms yet, only beta for Solaris,
Linux, and Windows as far as I know.  Nothing on HP yet.
There was also a good deal of output to the console (stderr).  Here's the end of it:

Exception in thread "Thread-2" Exception in thread "Thread-2" call:17285
Exception in thread "Thread-2" Exception in thread "Thread-2" call:17301
Exception in thread "Thread-2" Exception in thread "Thread-2" call:17317
call:17318
Exception in thread "Thread-2" Exception in thread "Thread-2" call:17335
Exception in thread "Thread-2"
More testing on Red Hat 7.2, this time with the 1.4.2 JRE/OJI installed:

Java to JS tests.  Failed test #7 with the following output:
enum-001 The variable statment
test enumeration of a java object: element at 0 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 1 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 2 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 3 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 4 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 5 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 6 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 7 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 8 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 9 = java.lang.Object@1a9334     
FAILED: expected PASSED!
test enumeration of a java object: element at 10 = java.lang.Object@1a9334     
FAILED: expected PASSED!
...
...
test enumeration of a java object: element at 678 = java.lang.Object@1a9334    
 FAILED: expected PASSED!
test enumeration of a java object: element at 679 = public java.lang.Object
java.util.Vector$1.nextElement()      FAILED: expected PASSED!
test enumeration of a java object: element at 680 = java.lang.Object@1a9334    
 FAILED: expected PASSED!
Test # 8 failed with the following:

enum-002 The variable statment
test enumeration of a java object: element at 0 = false     FAILED: expected true

Test #10 passed.

This was using Mozilla 1.4a with Java 1.4.2 on Redhat 7.2.
Test # 8 also produced similar stderr output:

call:17353
call:17359
call:17360
call:17374
call:17375
Exception in thread "Thread-2" call:17383
Exception in thread "Thread-2" call:17390
call:17391
call:17409
call:17410
Exception in thread "Thread-2" 
Running the tests now with Mozilla 1.2.1 using 1.4.2 Java and Redhat 7.2:

Test # 7 failed exactly as with 1.4a.

Test #8 crashed the browser.  I will attach the error log produced.
Also for Mozilla 1.2.1 using 1.4.2 Java and Redhat 7.2:

Test # 10 passed.


Running the tests now with Mozilla 1.3 using 1.4.2 Java and Redhat 7.2:

Same results as Mozilla 1.4a.  All passed other than #7 and #8.
The Linux version of Java 1.4.2 is:
Java(TM) Plug-in 1.4.2-beta-b19
Using JRE version 1.4.2-beta Java HotSpot(TM) Client VM


For Solaris:
Java(TM) Plug-in: Version 1.4.2
Using JRE version 1.4.2-beta Java HotSpot(TM) Client VM
The lifecyle tests #2 and #3 also do not appear to work for numerous
platform/browser combinations.

Mozilla 1.2.1 Beta for Solaris
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030313
Java(TM) Plug-in 1.4.2-beta-b19

Neither test output anything to the Java Console.  Expected to see Applet Init,
Start, Stop messages.

Is anyone looking at this bug?

It is critial to IBM and Rational Software that this problem is addressed ASAP.
 We have been running into numerous problems with LiveConnect and are starting
to think that it is not a technology worth investing time or effort into working
with.
Mozilla 1.4a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Java(TM) Plug-in 1.4.2-beta-b19

Lifecyle Test #2
Output in the applet: 
init: thread=thread applet-PrintThread.class, thread
group=http://www.mozilla.org/quality/browser/front-end/testcases/oji/-threadGroup
start: thread=thread applet-PrintThread.class, thread
group=http://www.mozilla.org/quality/browser/front-end/testcases/oji/-threadGroup

Output to Java Console:
Nothing.

Output to Stderr:
Warning: 
    Name: HorScrollBar
    Class: XmScrollBar
    The specified scrollbar value is greater than the maximum
    scrollbar value minus the scrollbar slider size.
The expected output to the Java Console from Test #2 (reproduced from WinXP
NN7.02 1.4.2 JVM):

init: thread=thread applet-PrintThread.class, thread
group=http://www.mozilla.org/quality/browser/front-end/testcases/oji/-threadGroup
start: thread=thread applet-PrintThread.class, thread
group=http://www.mozilla.org/quality/browser/front-end/testcases/oji/-threadGroup
stop : thread=thread applet-PrintThread.class, thread
group=http://www.mozilla.org/quality/browser/front-end/testcases/oji/-threadGroup
destroy: thread=thread applet-PrintThread.class, thread
group=http://www.mozilla.org/quality/browser/front-end/testcases/oji/-threadGroup


The expected output to the Java Console from Test #3 (reproduced from WinXP
NN7.02 1.4.2 JVM):

initializing... 
starting... 
stopping... 
preparing for unloading...

On UNIX based browsers, there is NO output to the Java Console and LiveConnect
is BROKEN!
Depends on: 64319
Changed summary to be more accurate.
Summary: No Mozilla browser seems to fully support LiveConnect → No Mozilla UNIX browser and Java Plug In fully supports LiveConnect
The lifecycle tests actually all worked, for the first time that I've seen on
any UNIX platform. This was with Mozilla 1.4a on RedHat 7.2 and the 1.5.0 JRE.

Linux qwin145 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown

java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b06)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b06, mixed mode)

All of the JS to Java tests seemed to pass, except #10 and #13 which displayed
only the header and nothing else.

But test #7 on the Java to JS tests proceeded to print out FAILURE for all of
the test cases, and then crash the browser with the following, plus the attached
crash log.

INTERNAL ERROR on Browser End: Plugin instance index out of bounds -65

System error?:: Success

[1]+  Exit 255                ./mozilla

Test #8 of Java to JS crashed with the following, without displaying anything on
the page:
INTERNAL ERROR on Browser End: Plugin instance index out of bounds -65

System error?:: Resource temporarily unavailable

[1]+  Exit 255                ./mozilla

It just looks like some of the latest fixes in 1.4.2 haven't been merged over to
1.5.0 yet.  But we still don't have anything that PASSES the Java to JS tests #7
and #8.  Best I can reproduce so far is FAILED without a crash or hang.
I forgot to mention that the Talkback ID for comment #18 is: TB20017414H
Severity: major → critical
Ugh.  Nevermind that Talkback ID (for comment #18), it's not valid for this defect.

I did manage to get the Java Console output for the failure on Java to JS test
#7.  The crash in this case is intermittent.


Security.PrivilegedActionException: java.lang.IllegalAccessException: Class
sun.plugin.liveconnect.PrivilegedCallMethodAction can not access a member of
class java.util.Vector$1 with modifiers "public"
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation$2.run(SecureInvocation.java:200)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation.CallMethod(SecureInvocation.java:179)
	at sun.plugin.navig.motif.AThread.handleRequest(Native Method)
	at sun.plugin.navig.motif.AThread.JNIHandleLoop(AThread.java:35)
	at sun.plugin.navig.motif.AThread.run(AThread.java:27)
Caused by: java.lang.IllegalAccessException: Class
sun.plugin.liveconnect.PrivilegedCallMethodAction can not access a member of
class java.util.Vector$1 with modifiers "public"
	at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57)
	at java.lang.reflect.Method.invoke(Method.java:317)
	at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(SecureInvocation.java:556)
	... 7 more
java.security.PrivilegedActionException:
java.security.PrivilegedActionException: java.lang.IllegalAccessException: Class
sun.plugin.liveconnect.PrivilegedCallMethodAction can not access a member of
class java.util.Vector$1 with modifiers "public"
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation.CallMethod(SecureInvocation.java:179)
	at sun.plugin.navig.motif.AThread.handleRequest(Native Method)
	at sun.plugin.navig.motif.AThread.JNIHandleLoop(AThread.java:35)
	at sun.plugin.navig.motif.AThread.run(AThread.java:27)
Caused by: java.security.PrivilegedActionException:
java.lang.IllegalAccessException: Class
sun.plugin.liveconnect.PrivilegedCallMethodAction can not access a member of
class java.util.Vector$1 with modifiers "public"
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation$2.run(SecureInvocation.java:200)
	... 5 more
Caused by: java.lang.IllegalAccessException: Class
sun.plugin.liveconnect.PrivilegedCallMethodAction can not access a member of
class java.util.Vector$1 with modifiers "public"
	at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57)
	at java.lang.reflect.Method.invoke(Method.java:317)
	at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(SecureInvocation.java:556)
	... 7 more
Attachment #121202 - Attachment mime type: application/octet-stream → text/plain
Attachment #121202 - Attachment description: Mozilla 1.2.1 w/ Java 1.4.2 on RedHat 7.2 crash log → Mozilla 1.2.1, 1.4.2-b19 JRE , RedHat 7.2, Java to JS Test #8 crash log
This appears to be in the process of redesign.  From netscape.public.mozilla.oji:


> Joshua Xia wrote:

> > Sun's Java Plugin team and Browser Java team have investigated a lot
> > of bugs which related to Java, and focus on OJI/Liveconnect 's
> > stability and performance.
> > 
> > We have blueprint of redesign and the solution is to achieve the
> > following three goals:
> > 
> > 1. XPCOM independent: 
> > The new interface between OJI and JPI should be XPCOM independent. The
> > main purpose of doing this is to break the dependencies with
> > constantly changing Mozilla XPCOM APIs.
> > 
> > 2. JNI Free:
> > The interface between OJI and JPI will hide JNIEnv from browser side.
> > Exposing JNIEnv interface to browser has at least two shortcomings:
> >  1) JNIEnv interface is a low level interface to JVM functionality.
> > Exposing a low level interface to the browser makes the browser to
> > call into JVM randomly. This can cause a lot of subtle bugs.
> >  2) It causes a lot of overheads especially for out-of-proc
> > implementation.
> > 
> > 3. Gecko Plug-in API based:
> > Gecko Plug-in API  has been adopted by different Netscape Plug-in
> > vendors for a long time. It is a stable C style API.   Although it may
> > not be complete, the C style interface is a durable solution for cross
> > platform binary compatiblity.
> > 
> > If we can achieve these three goals, we can run java/liveconnect on
> > browser more stabile and efficient.
> > 
> > Soultion on browser side:
> > Create a new module works as OJI/Liveconnect 's function, this module
> > will:
> > 
> > 1. Hide XPCOM, only provide C-style functions for JPI
> > 2. Implement liveconnect function by using the APIs that JPI provides
> > (don't use JNI)
> > 3. Backward compatibility, use different modules (select between
> > OJI/Liveconnect and New module on runtime) according to different
> > version JPI.
> > 
> > Welcome to push our OJI/Liveconnect Redesign again!

> 
> What's the timeframe for this?


Sun's Java Plugin team plan to add new APIs in "Tiger" project (J2SE
1.5) which will be code frozen on this Aug.
So we expect to add a new module on mozilla 1.5

Thanks for push!
Confirming to make sure it shows up on people's lists.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Xiaobin:
is the following exception reasonable?
Security.PrivilegedActionException: java.lang.IllegalAccessException: Class
sun.plugin.liveconnect.PrivilegedCallMethodAction can not access a member of
class java.util.Vector$1 with modifiers "public"
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation$2.run(SecureInvocation.java:200)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation.CallMethod(SecureInvocation.java:179)
	at sun.plugin.navig.motif.AThread.handleRequest(Native Method)
	at sun.plugin.navig.motif.AThread.JNIHandleLoop(AThread.java:35)

Thanks!
Status: NEW → ASSIGNED
This is a well-known problem. It has been logged into Sun's bugtraq bug. The 
reason is "Enumeration" from Vector.elements() is implemented as an inner class 
in JDK and it is not possible to call into private class from javascript.

->kyle
Assignee: joshua.xia → kyle.yuan
Status: ASSIGNED → NEW
Any updates on this?

It seems that J2SE 1.5.0 has been released, and several updates, and LiveConnect
is _more_ likely to cause browser crashes than with 1.4.2.

Sun just gave up?
Assignee: yuanyi21 → pete.zha
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
Summary: No Mozilla UNIX browser and Java Plug In fully supports LiveConnect → No Mozilla UNIX browser and Java Plugin fully supports LiveConnect
Product: Core → Core Graveyard
QA Contact: dsirnapalli → java.oji
Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: