Closed Bug 60018 Opened 24 years ago Closed 23 years ago

LiveConnect does not work with JavaObjects - JSObject.getMembers does not work, returns null

Categories

(Core Graveyard :: Java: OJI, defect, P1)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: gary.kind, Assigned: beard)

Details

Attachments

(5 files)

Packaged test case as jotest.zip
2.31 KB, application/octet-stream
Details
Patches to fix for MRJ plugin.
18.71 KB, patch
Details | Diff | Splinter Review
Updated patch to deal with conflicts in lcglue.cpp v1.32
2.95 KB, patch
Details | Diff | Splinter Review
Added appropriate NS_REINTERPRET_CASTs
5.53 KB, patch
Details | Diff | Splinter Review
Updated to v1.33 of lcglue.cpp (only 1 conflict!)
5.35 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
BuildID:    Netscape 6, build date 11/05/2000

Using liveconnect, Oracle Tools products need the ability to use a JavaScript 
Object to set 2 of its members to the DOM window and DOM document.  Our code 
can then can then create a JavaObject by doing the following:
var OracleObj = new Packages.<classname>();
We then would pass in the JavaScript object with our parameters, e.g.
OracleObj.load(ourParams);
In the load method for the JavaObject, we need to do the following:
JSObject win = (JSObject) ourParams.getMember("windowMember");
JSObject doc = (JSObject) ourParams.getMember("documentMember");
In Netscape 6, both of these calls fail, whereas in Netscape 4.7,
my testcase works perfectly.
We can NOT use an Applet.   Our applications are large and complex.
If we use an Applet and a user goes to another URL, then returns to our 
Application, it would reload the entire application.  This is unacceptable to 
our customers.  To avoid this problem we use a JavaObject (as I described 
above), which does not get unloaded as the user changes pages and comes back.
Being able to use a JavaObject instead of an Applet AND do a getMember on any 
JSObject is critical for Oracle Tools products.  I consider this a showstopper 
and it needs to be addressed as quickly as your schedule permits.

Reproducible: Always
Steps to Reproduce:
1. Use the jotest.html that is included in "Additional information" below.
2. Take the Cherokee.java file included in "Additional information" below, 
place it in a directory c:\java\lang\Cherokee.java.
3. Compile it into c:\java\lang\Cherokee.class
4. Zip \java\lang\Cherokee.class into your JDK 1.3 rt.jar file. Using Winzip, 
verify that Cherokee.class is in your rt.jar file and its directory is 
java\lang.
5. Bring up the Netscape 6 browser and open the java console.
6. run the jotest.html file provided.
7. In the console, you will see that the Cherokee JavaObject is created, but 
the calls in the load method to params.getMember both return null.  NOTE:  This 
works fine under Netscape 4.7
*
IMPORTANT NOTE:  The reason that Cherokee.class is put into rt.jar under 
java/lang is that Netscape 6/JDK 1.3 does not use the classpath the way it did 
under JDK 1.1 and I can't figure out a way to tell javascript how to find the 
Cherokee.class file.

Actual Results:  The System.out.println statements in the JavaObject's load 
method indicate the dom win and doc are both null:
***********
Starting jotest.html

*** Cherokee constructor: ***Hello

*** jotest.html: calling Cherokee.load() ****


*** cherokee.load: Start of method ***

*** cherokee.load: msg is Cherokee.load

*** cherokee.load: win is null ***

java.lang.NullPointerException

	at java.lang.Cherokee.load(Cherokee.java:55)

	at java.lang.reflect.Method.invoke(Native Method)

	at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source)

	at java.security.AccessController.doPrivileged(Native Method)

	at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)

*** cherokee.load: doc is null ***

*** cherokee.load: Using DOC to write html ***

java.security.PrivilegedActionException: 
java.lang.reflect.InvocationTargetException: java.lang.NullPointerException

	at java.lang.Cherokee.load(Cherokee.java:81)

	at java.lang.reflect.Method.invoke(Native Method)

	at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source)

	at java.security.AccessController.doPrivileged(Native Method)

	at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)



Expected Results:  I would have expected no errors and a valid DOM window and 
document returned to the applet's method as JSObjects.  The calls win.call
("showAlert", msg); and doc.call("write", msg);  should both have worked 
correctly.

Source code to jotest.html:
********
<html>

<head>
<title>Live Connect using a JavaObject</title>
</head>
<body>
<form ID="form1" name=myForm>
<input ID="field1" Type=text value="Live Connect using a JavaObject" 
name="fieldOne">
<input ID="button1" Type=button value="Set Cookie" name="buttonOne">
</form>

<script>


	function showAlert(txt)
	{
	    alert ("JavaScript 'showAlert': called from " + txt);
	}

   var params =
        {
		    domwin: window,
			domdoc: document,
			serverhost: "tkrtc-server.us.oracle.com"
		};

   java.lang.System.out.println("Starting jotest.html");

   var htmlForm = new java.lang.Cherokee("Hello");

   java.lang.System.out.println("*** jotest.html: calling Cherokee.load() 
****\n");
   htmlForm.load(params);
   java.lang.System.out.println("*** jotest.html: returned from Cherokee.load() 
****\n");

</script>
</body>
</html>
*************************************************************
Source to Cherokee.java
*************************************************************
package java.lang;

import netscape.javascript.*; 

public class Cherokee
{ 
    JSObject win = null;
	JSObject doc = null;

	//-----------------------------------------------------------------
	// Constructor
	//-----------------------------------------------------------------

    public Cherokee(String txt)
	{
 	   System.out.println("*** Cherokee constructor: ***" + txt);
    }   
    

    //--------------------------------------------------------------------
	// Public Methods
	//--------------------------------------------------------------------

    public void load(JSObject params)
	{
        System.out.println("*** cherokee.load: Start of method ***");

        String msg[];
        msg = new String[1];

        // Create a local copy of the cookie text
        msg[0] = "Cherokee.load";
        
        System.out.println("*** cherokee.load: msg is " + msg[0]);

        try
		{
			// Get the DOM window through params             
			win = (JSObject) params.getMember("domwin");

			if (win == null)
			{
			   System.out.println("*** cherokee.load: win is null 
***");
			}
		}
        catch (Exception e)
		{
            // Don't throw exception information away, print it.
            e.printStackTrace();
        }

        try
		{
			// Call the JavaScript function to set the 
cookie             
			win.call("showAlert", msg);
		}
        catch (Exception e)
		{
            // Don't throw exception information away, print it.
            e.printStackTrace();
        }

        try
		{
			// Get the DOM window through params             
			doc = (JSObject) params.getMember("domdoc");

			if (doc == null)
			{
			   System.out.println("*** cherokee.load: doc is null 
***");
			}
		}
        catch (Exception e)
		{
            // Don't throw exception information away, print it.
            e.printStackTrace();
        }

        System.out.println("*** cherokee.load: Using DOC to write html ***");
        msg[0] = "<H1><I>Cherokee.load</I><H1>";
		doc.call("write", msg);

        System.out.println("*** cherokee.load: End of method ***");
    }
}
cc'ing Patrick, Jeff -
Status: UNCONFIRMED → NEW
Ever confirmed: true
On second and third thought, this is a critical bug for Oracle products.  We 
must avoid the unloading of the Applet as the user goes to another page.  Our 
customers just won't accept this behavior.  If there is any way to get this to 
work and somehow get the DOM window into Java so we can callback into 
JavaScript, we would greatly appreciate it.
Severity: major → blocker
Priority: P3 → P1
I would respectfully submit that, once again, this is critical for Oracle 
products.  Could I have an update or schedule as to when this will be worked on?
Summary: JSObject.getMembers on does not work returns null → LiveConnect does not work with JavaObjects - JSObject.getMembers does not work, returns null
I am revising this bug so that the person assigned to this bug only has to fix 
one thing.  The real thing that we need to be able to do is use liveConnect to 
call JavaScript -> Java and Java -> JavaScript using a JavaObject created via, 
e.g. 
    var htmlForm = new java.lang.Cherokee();

    // Pass in the DOM window to the JavaObject, htmlForm
    // so that Java can call back into JavaScript via
    // window.call(<method name>, <args>);
    htmlForm.load(window);

You can read the rest of the bug description as to why this is superior to 
using an Applet.

Please, can somebody look into this right away?  This works on Netscape 4.7.
Mitchell, since you just finished 61284, can you take a look at this?

I have discussed this bug with rogerl; it looks like it is more OJI-related 
than LiveConnect. Therefore I'd like to assign it to Jeff, in case it should 
be considered together with similar OJI bugs he's been handling recently ...


Changing component to OJI -
Assignee: rogerl → edburns
Component: Live Connect → OJI
QA Contact: pschwartau → shrir
And reassigning to Jeff -
Assignee: edburns → jeff.dyer
Could someone please work on this?  I am running up against things such as 
calls to window.open(URL, title, "modal=yes") where I need to be able to talk 
to the javascript in the modal dialog.  I cannot kick off another Applet in the 
URL, cause I get another security violation from Java.  When I try to use a new 
Java Object, I get security violations also.  How the heck is anybody supposed 
to use LiveConnect when it can barely be used, even by an Applet?  It can only 
be used in the most simple applets.  Please, somebody work on this stuff and 
see if you can get it a little more functional?
Gary, I am looking at this from the JS side, and I believe Stanley is looking at
it from the java side, but the problems will be tough to solve. Java and JS use
two very different security models, and getting them to interact securely is a
challenge. I am exploring ways to make the JS security model more compatible
with Java, but this will not be quick. Beleive me when I say this is a problem I
would like to see fixed as well, but realistically I don't expect fully
functional LiveConnect support until Netscape 6.5.
BTW, this bugs MUST be fixed.  I am having to do all sorts of things to get
around these access denied messages and security violations, such as creating my
own event queues in javascript so that all the events in modal dialogs get
enqueued while the dialog is visible.  Once the dialog is closed, I then deliver
all the dialog's events through javascript to my java applet.  This works in
most cases.

Now I have come across another roadblock that I am unable to workaround because
of the security restrictions.  It will not be enough to just have them
nominated.  We simply must have them fixed or our product will not be able to go
out on Netscape.  I am sorry but that is the simple truth.
Keywords: nsbeta1
Will the fix of 63466 (fixed some problems of a number of JSObject methods, like
call(), getMember(), getSlot(), eval(), etc.) also resolve the problem here?
I tried to run the test case with the patch of 63466 on Solaris, but the case
here seemed to be for Windows only. Gary, can you modify it to make it work for
Unix? Or you may give a try of the patch of 63466.
I will try this again with the latest Mozilla nightly build for Windows to see
what has changed.  After reviewing my original bug source, the real issue here
is the ability to use a javaObject in javascript instead of an Applet.  If we
could just pass in the DOM window object as a JSObject in the call to
htmlForm.load(), we would be OK.  However, this brings up the issue of the
persistence of the DOM window as a JSObject in Java.  I have found that each
time I want to make a call from Java -> Javascript (remember, I am now using
an Applet), I have to call 'JSObject mWin = JSObect.getWindow(this);', where
'this' is the Applet.  I have to do this because 'mWin' is not persistent.  This
must also be solved for JavaObjects.   If I were to pass in the DOM window
object to the load method and it is not persistent, how do I get it again?  If I
pass in the 'params' object, I can call params.getMember("domWin") to get the
DOM window -- but I don't want to have to do that each time I want to call into
the javascript.  All this has to be solved before Oracle can put out a
production product on Netscape.
Did some testing on Solaris and Windows, here are our testing setup and results:

- Setup for testing:
  Instead of using jar as in the original test case, a simple change can make 
the classpath work: in the java control panel, add the following line to the 
runtime parameters box:
     -Xbootclasspath/a:c:\bug60018     
Then I put Cherokee.class in my c:\bug60018.

- Test results:
On Windows, the call of getMember(docwin) returned a null. A breakpoint was set 
at the beginning of GetMember() in nsCLiveconnect.cpp, but was not caught, 
which seemed to indicate that somehow before Java plugin calling the browser' 
GetMember() an error ocurred causing a null to be returned by getMember(). 

On Solaris, after calling getMember() in Cherokee, the browser exited with a -1 
in the call of get_msg() in handle_response() of remotejni.cpp, which seemed to 
indicate that some error happened in the communication between the Java plugin 
and the JVM.

- What's next:
Currently, a debug version of Java plugin is being built on Windows, in order 
to trace to find out why getMember() return a null. The building has turned out 
to be more bumppy than we had expected, and we hope we can get it done soon.




 












Please!  I just read Joe Chou's latest comments and he seems to be focussing on
the getMember call returning a null value.  While that is something that needs
to be solved, the Important thing is the fact that we need to be able to use an
JavaObject!!   I have said this multiple times throughout this bug and my test
case shows this.  If Joe is using my testcase, he might want to check how the
MAYSCRIPT html applet tag property affects the ability to call back and forth
between Java and Javascript.  Without this applet tag property liveconnect does
not work.  Perhaps one of the reasons a JavaObject does not work is that there
is now MAYSCRIPT setting to allow liveconnect to work?  Please read all of my
comments and focus on the real issue here, not just that getMember doesn't work.
Joe Chou also asked if the work on 63466 might help with this bug.  Once again,
that has to do with getMember, eval, etc. while using an Applet and does not
address the main issue of needing to use a JavaObject.
To find out why getMember returning a null is just the starting point of the
debugging, not the final objective, Gary. 
Per this morning's tracing on Windows, it appeared that the reason of
getMember() returning a null is Java plugin can not find the plugin instance of
the call in the instance map. 

    
    

    
  
Going to do some debugging on this as soon as my current build finishes.

Assignee: jeff.dyer → beard

    
    

    
  
I talked to Joe Chou and Xiaobin Lu about this last night.  It looks like the
Sun Java Plug-In expects a PluginInstance to be around from which to pull
information (I don't know what info, sorry).  But since the test page in
question doesn't contain an APPLET, EMBED, or OBJECT tag, evidently the browser
doesn't think it should create a PluginInstance (and why should it?), so the
Java Plug-In doesn't get the info it currently requires.

I don't know if this is the case with the MRJPlugin.

Joe and Xiaobin are looking into a way for LiveConnect to make up a
PluginInstance and hand it to the Java Plug-In.  This doesn't sound like the
best solution to me --- it seems that the OJI module and Java Plug-In should
ideally realize that there are ways to activate Java besides the APPLET, EMBED,
and OBJECT tags --- but I doubt that Java Plug-In is going to be able to make
any change in time for the next release of Mozilla or Netscape 6.  For now, I
recommend finding a way to modify the browser.

Patrick, does what I said about lack of a PluginInstance ring any bells for you?
 I'm writing this comment here in case it's helpful to you, while Joe and
Xiaobin continue to check it out.


    
    

    
  
Currently, before dispatching a JSObject call(getWindow(), getMember(), eval(),
etc.), Java plugin first finds a plugin instance which is instantiated by the
browser thread (e.g., when encountered an applet tag in layout). Then uses the
plugin to obtain the nsIJVMManager for creating a proxy JNI, nsICapsManager for
creating principal, and nsILiveConnect for doing the dispatch. All these
interfaces are obtained from nsIPluginServiceProvider. If the plugin is not
found (not being instantiated by the browser), the dispatching will fail, which
causes a null to be returned.

In Gary's test case, since there is no Java plugin related tag (Embed, Object or
Applet), no plugin instance is instantiated, and therefore the Java plugin's
dispatch fails.

As suggested by Gary, we added an applet tag into the HTML page between the form
and the JavaScript, and the JSObject calls (getMember(), call(), etc) seemed
working OK (depending on which version of Java plugin is used, you may need to
change couple lines of code, mainly to cover the case of null url). That seems
to suggest that a possible solution to the problem may be to instantiate a
plugin instance with the right contents in the right spot of LiveConnect, before
invoking a Java class's method.

The above is based on our testing on the Windows platform. Since the
implementation of Java plugin is different between Windows and Unix, the patch
for each platform needs to match its own implementation.

    
    

    
  
I can only speak for the MRJ plugin on this bug, but I have been able to confirm 
it and have figured out a workaround. Along the way, I believe I found a 
reference count leak in the OJI component (see the patch to lcglue.cpp), and 
another dangling JSContext* problem. On to my diagnosis and a workaround within 
the MRJ plugin.

1. The problem is that the MRJ plugin's implementation of the 
netscape.javascript.JSObject native methods were written to only work if called 
from a Java applet, or at least from a thread created by a Java applet. So, I 
changed the native methods to relax that constraint, and to pass NULL for the 
securitySupports parameter in that case. This means, use whatever security 
principals that were current on the NSPR thread that called into Java, which 
typically means the calling script. The callbacks in mozilla/modules/oji/src/
lcglue.cpp seem to fall back on that in the case when a NULL security context is 
passed to them.

2. Having gotten past the initial problem, the calls to JSObject.getMember() and 
JSObject.call() used by the test case now work, and the alert() comes up with the 
message "JavaScript 'showAlert': called from Cherokee.load". However, soon after 
this call, LiveConnect crashes. This problem is a side-effect of a JavaObject 
getting finalized by the JS GC, which calls jsj_EnterJava(), which hits this 
assert:

JS_ASSERT((jsj_env->recursion_depth == 0) || (jsj_env->cx == cx));

The assert fires because the jsj_env->recursion_depth == 1, and jsj_env->cx != 
cx. The cx passed in is a JSContext that is associated with the alert window, and 
when it gets assigned to jsj_env->cx, it dangles, because jsj_ExitJava() can't 
restore it to the previous JSContext since (jsj_env->recursion_depth > 0). There 
are two possible fixes for this. One might be to defer finalization, perhaps by 
telling the GC that it isn't safe to do this right now. Alternatively, my patch 
just leaves jsj_env->cx alone, which seems to work for this purpose, but may not 
be appropriate in general.

Status: NEW → ASSIGNED

    
    

    
  
Brendan, is there a safe way to inhibit finalization, i.e. defer it, until all 
pending calls from JS into Java complete? Or is just leaving the JSContext bound 
to the current jsj_env a safe enough fix? During finalization it seems to be safe 
enough.


    
    

    
  
Thanks Beard!

    
    

    
  
Dup of Bug #59447 ?

    
    

    
  
Joe:
   Can you verify Chris statement please?

    
    

    
  
The bugs are related, but this bug doesn't involve applets, while the other one 
does.


    
  
Target Milestone: --- → mozilla0.9

    
    

    
  
Joe Chou:

Can you please talk to Patrick and find out about the leak in lcglue.cpp?

This leak should probably be fixed.

Ed

    
    

    
  
Is that part of the patch (in lcglue.cpp)?

    
    

    
  
Yes, it's fixed by getter_AddRefs(scriptContext->GetGlobalObject()).


    
    

    
  
I looked at bug #59447 and it does have a lot of the same problems I have been 
seeing:
1) Calls to javascript outside of the Applet's init method do not, for some 
erroneous reason, have the same security settings and often fail with a security  
violation.

2) If you continued on with this bug and tried to use win.call(method, args) 
later on in your java code w/o refreshing "win", that is calling 
   JSObject win = JSObject.getWindow(this); 
you would see that win.call does not work because win is null!  There is a 
persistence issue here that must be resolved.  We cannot be expected to keep 
making calls to JSObject to get DOM windows and Documents each time we need to 
use them.  This is a performance hit we are not willing to take and because of 
the present instability of LiveConnect, we cannot take this hit.  When we get
a DOM object through JSObject, we must be able to keep it around and for it to 
remain valid.

I should probably file a separate bug about both of these, especially #2.  If 
you fix bug 60018, then #1 will be a moot point because I will no longer have to 
use an applet.

    
    

    
  
Xiaobin and I have investigated this bug further and, as was already known, the 
reason for the crash is an unexpected null url in the native implementation of 
getMember(), in the java plugin source:

oji-plugin\src\win32\core\natives.cpp:

JNIEXPORT jobject JNICALL 
Java_sun_plugin_javascript_navig5_JSObject_JSObjectGetMember()

...

pszName = env->GetStringChars(name, (jboolean*)0);
pszUrl = env->GetStringUTFChars(url, (jboolean*)0);     
len = env->GetStringLength(name);

...

In the "Cherokee" testcase this url is null.

The reason this url is null is that there is no sun.applet.AppletClassLoader on 
the call stack.  This causes the SecurityContext to get created without a 
domain, which cauese SecurityContext.getURL() to fail.  Please see file

E:\ladybird\ext\plugin\java\src\sun\plugin\javascript\navig5\JSObject.java

methods run() (line 600) and method getURL() line 541.

Of course, it makes sense that there is no AppletClassLoader on the stack 
because there is no applet.  The big question: how should we fix this (more 
importantly can this be fixed without changing the java plugin)?  Why do we 
need the AppletClassLoader?  To get the ProtectionDomain.  How do we get a 
ProtectionDomain without an AppletClassLoader?

Jeff?  Stanley?



    
    

    
  
The solution in my patch is to pass NULL for the securityContext parameter if no 
applet can be identified for the call. I think your plugin can use this solution 
as well. In this case, as long as you're calling into nsILiveconnect on the same 
thread as called out to Java, you'll use the same JSPrincipals and accesses to 
DOM properties should work.


    
    

    
  
 You should fix your HTML and Java class in the following way:
package com.oracle;
instead of 
package java.lang;
in Cherokee.java
put it somewhere in classpath, and use
var htmlForm = new Packages.com.oracle.Cherokee("Hello");
instead 
var htmlForm = new java.lang.Cherokee("Hello");
in HTML file.

With this modification your code works with Waterfall JVM service.

 Nikolay.


    
    

    
  
Nikolay:
   Actually in a testcase we are using, we remove the java.lang package and 
still does not work.
   I think the problem here is the current java plugin side expects an applet 
to make all things work and the testcase can not satisfy the requirement. The 
fix should be either in browser side which add such a fake applet to cheat the 
plugin or the plugin side should consider the case which liveconnect call may 
not limited only for the applet.

    
    

    
  
Ed:
   Sorry for using your account to post something here. I forgot to log out 
from your account. Now it is ok.
    

    
    

    
  
  I tried to create a pluginInstance and pluginInstancePeer without having 
pluginInstanceOwner invovled, but it seems that it fails because the java 
plugin side checks to see if the plugin associate with a window or not and if 
not, it also fails to activate the liveconnect. However, the key to set up the 
window is to use nsPluginInstanceOwner.
 
  Maybe I think the solution is to add an applet tag and find out why it throws 
exception when it tries to call document.write().

    
    

    
  
   Maybe this is an ugly way to solve this problem. But it will be an 
workaround which you don't need to worry about the crash of java plugin and 
Xbootclasspath. Meanwhile, we are working on a better solution.
  
   I just made an applet which basically a wrapper of the Cherokee class. For 
example it is called CherokeeApplet.
------
import java.applet.Applet;

public class CherokeeApplet extends Applet {
   private Object cherokeeObj;

   public init() {
      cherokeeObj = new Cherokee();
   }

   public Object getObject() {
      return cherokeeObj;
   }
}

  This is an easy applet. And you need to modify the HTML page to add an applet 
tag.
  <Applet code = CherokeeApplet.class Name = CherokeeApplet MAYSCRIPT = true  
width = 0 height =0 > </Applet>

  And instead of calling "htmlForm = new Packages.Cherokee()", you just 
call "htmlForm = document.getMember("CherokeeApplet").getObject();".
  As you know after this change, because it has the same problem of bug 59447. 
So after that bug is fixed, probably this should work too. Currently 59447 has 
some progress with Nikolay's patch. 
  
   



    
    

    
  
I would like to check in the patch to mozilla/modules/oji/src/lcglue.cpp, ahead 
of the patch in bug #5403, which is pretty sizeable. Can I please get a r/sr on 
the latest attachment? This fixes an important memory leak.


    
    

    
  
r/sr=brendan@mozilla.org, and maybe change those old-style casts to
NS_REINTERPRET_CAST or NS_STATIC_CAST as appropriate?

/be

    
    

    
  
Ed: can you review this patch tonight, before check-in deadline?

    
    

    
  
Ed:
   Could you have a quick review of Patrick's patch? I reviewed this patch and 
it looks good.

Xiaobin

    
    

    
  
ra=edburns

Tested on win32.

    
    

    
  
Fixes checked in. Only the MRJ plugin changes remain to review and check in.


    
    

    
  
MRJ plugin fixes checked in.

Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
I assume that this means the "bug/enhancement request" is fixed?  If so, when 
will it make it into the nightly Windows builds of Mozilla?

    
    

    
  
gary: it's in the trunk, it should be in the nightly that you can retrieve 
today; if not today, then tomorrow.

By the way, stopped by your office last Friday to meet you in person; sorry we 
missed you.  Ask Stephen Tom about it.

    
    

    
  
Gary, it should be noted that Patrick's fix is just a memory leak fix.  The real
problem of the lack of ability for LiveConnect to use java classes without an
applet being present is still present.

I'm going to re-open this until we can get this problem fixed across all java
implementations.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
It looks to me that it will not be fixed (beyond what was fixed already) in 0.9. 
Could we move this into the next milestone?

    
    

    
  
This "WORKS FOR ME" with the MRJ plugin. Any other problems are likely defects in 
the Sun Java plugin. Another bug should probably be filed specificially against 
their plugin.

Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
I have opened <bug http://bugzilla.mozilla.org/show_bug.cgi?id=77194> to 
reflect the fact that this isn't fixed on Win32 and Unix.

    
    

    
  
Based on the above comment, marking Verified -
Status: RESOLVED → VERIFIED

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: