LiveConnect: getMember method of JSObject returns null.



Core Graveyard
Java: OJI
17 years ago
7 years ago


(Reporter: rpallath, Assigned: Xiaobin Lu)


Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [oji_working])


(4 attachments)



17 years ago
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..."

Comment 1

17 years ago
Created attachment 18918 [details]
Tar File: Contains src/html dir.

Comment 2

17 years ago
Added Mikhail on to CC list

Comment 3

17 years ago
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:

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


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;
  win=(JSObject) JSObject.getWindow(this);  
  System.out.println("win "+win);
  Object[] args = new Object[2];
  args[0] = win;
  args[1] = "document";
  System.out.println("doc "+doc);
  catch (Exception e) {System.out.println(e);};


Comment 4

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

Comment 5

17 years ago
This is a bug.

Comment 6

17 years ago
Reassign to jeff.
Assignee: edburns → jeff.dyer


17 years ago

Comment 7

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


17 years ago
Whiteboard: [oji_working]

Comment 8

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

Comment 9

17 years ago
Per conversation with Patrick, reassigning to him - 
Assignee: jeff.dyer → beard

Comment 10

17 years ago
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? 

Comment 11

17 years ago
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.

Comment 12

17 years ago
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  

2) If you continued on with this bug and tried to use, args) 
later on in your java code w/o refreshing "win", that is calling 
   JSObject win = JSObject.getWindow(this); 
you would see that 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.

Comment 13

17 years ago
Updated CC list to add avm/raghu

Comment 14

17 years ago
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.

Comment 15

17 years ago
Created attachment 30133 [details] [diff] [review]
Diff for nsScriptSecurityManager.cpp that fixes this bug

Comment 16

17 years ago
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.

Comment 18

17 years ago
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.

Comment 19

17 years ago
Created attachment 30207 [details] [diff] [review]
One more hacky fix for this bug.

Comment 20

17 years ago
Created attachment 30251 [details] [diff] [review]
Improved patch that gives no performance impact in generic case

Comment 21

17 years ago
   Would you like to use the latest code from trunk to test your patch? Thanks 
in advance!

Comment 22

17 years ago
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. 

Comment 23

17 years ago
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.


Comment 24

17 years ago
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).

Comment 25

17 years ago
Reassign to myself!
Assignee: beard →

Comment 26

17 years ago
 Investigate this after the 77600 fixed.

Comment 27

17 years ago
    Can you add some comment here about Nikolay's patch?
    Thank you!
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.

Comment 29

17 years ago
Thanks, Mitch. I will do it later.


17 years ago
Depends on: 84082

Comment 30

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

*** This bug has been marked as a duplicate of 46518 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 31

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


15 years ago
QA Contact: pmac → petersen


7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard


7 years ago
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.