Closed Bug 59447 Opened 24 years ago Closed 23 years ago

LiveConnect: getMember method of JSObject returns null.

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 46518

People

(Reporter: rpallath, Assigned: xiaobin.lu)

References

Details

(Whiteboard: [oji_working])

Attachments

(4 files)

Tar File: Contains src/html dir.
342.00 KB, application/x-tar
Details
Diff for nsScriptSecurityManager.cpp that fixes this bug
791 bytes, patch
Details | Diff | Splinter Review
One more hacky fix for this bug.
1.96 KB, patch
Details | Diff | Splinter Review
Improved patch that gives no performance impact in generic case
2.83 KB, patch
Details | Diff | Splinter Review 
Usually  for invoking any 'document' method thru' a LiveConenct call (java to
JavaScript) we get 
1) the window of that loaded page.
2) Get the document from the Window 
3) and then invoke the getMemebr method to access any of the relevant DOM
objects on that page.

It turns out that, the first call of getMember thru'a  Window object
     win = JSObject.getWindow(this)    
    doc = (JSObject)win.getMember("document");

to get an handle of the document object works, 
but then subsequent invokation of  getMember method
with this new returned document JSOBject always returns null.

(NOTE: you need the fix for 53849 to be in place).

Steps to reproduce
------------------
Get the attchmt (a tar file)
Go to src dir.
compile the java file (JavaTOjs).

And load the page ' getMemberLC.html' from the HTML dir.

Click on RunTest.
Look at the Java COnsole

It indicates that "doc.getMember(testForm) is NULL..."

    
    

    
  
Added Mikhail on to CC list

    
    

    
  
This is a consequence of the new security manager not allowing gets and sets on 
dom objects because it can't find an object principal for the page. The work 
around is to write a script that returns the thing that you want. You can even 
parameterize the script with a name of the member you want to get. Like this:

<HTML>
<SCRIPT>
function getProperty(obj,p) {
    alert("getproperty " + p);
    return obj[p];
}
</SCRIPT>
<APPLET CODE="jconsole1.class" WIDTH=700 HEIGHT=300 MAYSCRIPT>
<PARAM NAME="command" VALUE="alert('hi')">
</APPLET>
<FORM>
<INPUT TYPE="button" NAME="go_button" VALUE="Go" 
onClick="document.applets[0].go()">
</FORM>

</HTML>

Then use this script method like this:

import java.applet.Applet;
import netscape.javascript.*;


public class jconsole1 extends Applet {
public JSObject j;
public void go()
 {
  try {
  JSObject win,doc;
  System.out.println("Start");
  win=(JSObject) JSObject.getWindow(this);  
  System.out.println("win "+win);
  Object[] args = new Object[2];
  args[0] = win;
  args[1] = "document";
  doc=(JSObject) win.call("getProperty",args);  
  System.out.println("doc "+doc);
  System.out.println("End");
  }
  catch (Exception e) {System.out.println(e);};
 }
}



    
    

    
  
Does  that mean 'getMember' is not being supported, or  is it that it is a bug
that need to be fixed.



    
    

    
  
This is a bug.

    
    

    
  
Reassign to jeff.
Assignee: edburns → jeff.dyer

    
  
Status: NEW → ASSIGNED

    
    

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

    
  
Whiteboard: [oji_working]

    
    

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

    
    

    
  
Per conversation with Patrick, reassigning to him - 
Assignee: jeff.dyer → beard
Status: ASSIGNED → NEW

    
    

    
  
Tested with Raju, and found out the following:
except getMember("document"), getMember of other members in the document
("forms", "applets", etc.) returned null if the method was not invoked in init()
of an applet. On the other hand, if it was called in init(), then getMember()
seemed working OK. For example, if getMember("forms") was called in init() of
an  applet, and it is called in another method in the applet, then the getMember
returned a valid JSObject pointing at the forms in the document. If it is not
used in init(), getMember("forms") returned null when invoked in another method
of the applet. Why? 

    
    

    
  
Per my analysis in bug #60018, if your Java plugin is passing a non-NULL 
nsISecurityContext in to nsILiveConnect::GetMember(), then it had better be the 
right one, meaning it had better have the proper codebase set up. My current 
workaround is that if JavaScript is calling directly into Java, and Java is 
calling back into JavaScript, then I pass NULL for the securitySupports 
parameter, because there's no applet/pluginInstance to associate with the call. 
This seems to have the desired effect of running the call with the same 
JSPrincipals as the calling JavaScript. This still leaves arbitrary Java threads 
out in the cold as it were.


    
    

    
  
Although this is not a duplicate of 60018, 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.

    
    

    
  
Updated CC list to add avm/raghu

    
    

    
  
Just post some finding of Nikolay, one of our engineers.
  Basically the doc.getMember("testform") fails in the call of JS_GetUCProperty
(cx, js_obj, name, length, &js_val) ( nsCLiveconnect::GetMember() 
js/src/liveconnect/nscLiveconnect.cpp). The reason of the failure is 
nsScriptManager::GetPrincipal returns NS_ERROR_FAILURE. Based on Nikolay's 
email, the reason is because the Java principal does not match Mozilla 
principals. Basically at this time, JS security check should fall back to 
global object. However, before fall back happens, this function alreay returns 
NS_ERROR_FAILURE which leads to the getMember call return nothing.
  Nikolay also posted a workaround to this problem.
 It just remove the return NS_ERROR_FAILURE in GetPrincipal function 
(mozilla/caps/src/nsScriptSecurityManager.cpp) and change it to return NS_OK.
We think this needs extra secuirty review. Maybe at this time we need to do 
more instead of return NS_ERROR_FAILURE.
 

    
    

    
  
Xiaobin, your explanations not exactly reflect my opinion (maybe I wasn't clear
in my mail). So. my opinion is - JS JavaObject doesn't provide correct
principals for nsScriptSecurityManager, and it falls back to global script
object principals. But this fallback cannot happen, as 
nsScriptSecurityManager::GetObjectPrincipal fails. 
Also I attached diffs for caps/src/nsScriptSecurityManager.cpp.
 Maybe better solition would be provide correct principals for JS Java Object.

    
    

    
  
This patch makes me nervous. The rest of nsScriptSecurityManager assumes that
the result of GetObjectPrincipal is non-null when the function returns NS_OK, so
I think this will cause crashes. The correct fix would be for LiveConnect to
provide the correct principal for the object.

    
    

    
  
OK, agree, my patch was kinda stupid :). Here newer version, more clean but
should be reviewed 
by Netscape JVM integration gurus. Here idea is, if in backtrace one encountered
JS Java object, 
he have to ask for script permissions, not object. I don't see, if it could be
dangerous, or not. It works for me (TM), and fixes this bug.  
Anyway, it would be nice if someone fix it by major extension to
js/src/jsj_JavaObject.c with using of proper native XPCOM object implementing
nsIScriptObjectPrincipal interface. If not, this hack should work.

    
    

    
  
Nikolay:
   Would you like to use the latest code from trunk to test your patch? Thanks 
in advance!

    
    

    
  
I'm sorry Xiaobin, I don't understand what do you mean. Try to apply this patch
to trunk (or rewrite a bit, if it don't work). It should work - test it. 

    
    

    
  
Nikolay, I applied your patch with my trunk build of Apr 10. It crashes when I 
tested the testcase. I am sorry if I make you confuse. I just want you to make 
sure it works with the latest code from trunk.

Thanks!



    
    

    
  
Well, why not to debug it a bit :)? 
Maybe some null pointer checks. Idea is here - if function has JS JavaObject
as it's grandparent - use script principals instead. Maybe it crashes on strcmp
with zero pointers - investigate it (honestly I have no disk space on my box for
another Mozilla tree and don't want to update to the trunk yet).

    
    

    
  
Reassign to myself!
Assignee: beard → xiaobin.lu

    
    

    
  
 Investigate this after the 77600 fixed.

    
    

    
  
Mitch:
    Can you add some comment here about Nikolay's patch?
    Thank you!
Status: NEW → ASSIGNED

    
    

    
  
Some nits on that last patch:
- Please use diff -u, not diff -c, when posting diffs to Bugzilla.
- Please use the same formatting as the rest of the file (eg. put opening braces
({) on their own line).
- Why #define a line of code that's only called once? Wouldn't it be clearer to
just inline it?

Except for these things, this looks OK to me, but I'd like to have Brendan Eich
review it, as he will understand the ramifications better. Please fix the above
and re-post it as a diff -u, because Brendan will ask.

    
    

    
  
Thanks, Mitch. I will do it later.

    
  
Depends on: 84082

    
    

    
  
  Since this bug has same problem as 46518, marking as dup.

*** This bug has been marked as a duplicate of 46518 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE

    
    

    
  
SPAM: reassigning OJI bugs to new QA, pmac. (227 bugs)
QA Contact: shrir → pmac

    
  
QA Contact: pmac → petersen

    
  
Product: Core → Core Graveyard

    
  
Summary: LiveConnet: getMember method of JSObject  returns null. → LiveConnect: getMember method of JSObject  returns null.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: