Subj : Re: the native() call...
To   : Oystein
From : Johnny Stenback
Date : Tue Jun 15 2004 11:52 pm

Seems to me like the code for logging calls from JS into XPCOM should be 
in XPConnect, not nsDOMClassInfo, since nsDOMClassInfo doesn't know all 
that is going on, for instance, when a call to a native C++ method 
comest through, nsDOMClassInfo knows little about the actual call, all 
it knows is that the method in qeustion was read off of an object, but 
beyond that it doesn't know if the call was actually made, or what the 
arguments were, etc. XPConnect knows more than this, though not all in 
all cases. There's a small set of methods that are defined in 
nsDOMClassInfo (document.open() being one, element.scrollIntoView() 
being another, options.add() the last one, I believe), and for those, 
XPConnect doesn't know that the function is called, just that the method 
was accessed.

And while XPConnect obviously deals with more than just what happens on 
a webpage, so does nsDOMClassInfo, but the calls that come from chrome 
can be filterd out in XPConnect, the security manager knows whether a 
call is from JS on a webpage or from chrome. 
nsIScriptSecurityManager::SubjectPrincipalIsSystem() will tell you which 
case you're dealing with, and based on that, you can filter your logging 
appropriately.

If you'd put your logging code in the JS engine hooks in 
xpcwrappednativejsops.cpp (XPC_WN_CallMethod() and XPC_WN_GetterSetter() 
would be a good start, all of which calls into 
XPCWrappedNative::CallMethod()). That should get most, if not all calls 
from JS into XPCOM (with the exception of those few methods that are 
dealth with in nsDOMClassInfo.cpp).

I hope this helps.

Oystein wrote:

> Again, thanks for the help Brendan!
> I am looking into nsDOMClassInfo, and it seems that this is the best place
> to put my logging mechanism. But in the specs, I am reading that XPConnect
> only will call the nsIXPCScriptable methods if the attribute is not defined
> in IDL. For example, GetProperty() is used only when retrieving an attribute
> that was not defined in IDL. So do I need to remove this attribute from IDL
> to be able to go through the scriptable methods in the helper classes?
> And is it also possible to intercept method calls using classInfo?
> 
> Oystein
> 
> "Brendan Eich" <brendan@meer.net> wrote in message
> news:40CF5C1F.2090902@meer.net...
> 
>>Oystein wrote:
>>
>>
>>>Take for example the |document| object. The |document| object is
> 
> represented
> 
>>>in the DOM as an XPCOM object that can be accessed using its idl
> 
> interface
> 
>>>and XPConnect. The |document| object is also an object in the
>>>js-engine,where it is a property of the window object. In addition
> 
> XPConnect
> 
>>>will build a wrapper object at runtime for the |document| object, so
> 
> that it
> 
>>>can handle property accesses between XPCOM and javascript objects. So
> 
> there
> 
>>>are actually three objects...
>>
>>No, the XPConnect wrapper for the XPCOM C++-implemented object is the
>>same as the one that you say is "in the js-engine".
>>
>>There are two objects, one JS and one C++, if you like.
>>
>>
>>>I believe the access control(if the executing
>>>script can execute a particular method) is done in the DOM, but I havent
>>>been able to figure out how this is done. (I thought that one of the
>>>parameters in the native() call was one of the determining factors in
>>>this...)
>>
>>Do you mean whether the "same origin" access control policy applies, or
>>whether a preference such as those described at
>>http://www.mozilla.org/projects/security/components/ConfigPolicy.html is
>>set to allow access to a method such as otherWindow.focus ?
>>
>>
>>>My ultimate goal is to log every access to the DOM that a downloaded
>>>javascript does. For example:
>>>var t = document.cookie;
>>>document.write("something");
>>>window.open("http....");
>>>
>>>I figured I need to completely understand the communication between
>>>spidermonkey and mozilla to know where to place my logging function. My
>>>initial idea was to place it in spidermonkey, but it seems there is no
> 
> way
> 
>>>to separate between downloaded scripts and chrome scripts in
>>>spidermonkey.(and I do not want to log access done by chrome scripts...)
>>
>>You should consider doing the logging in DOM code.  See
>>http://lxr.mozilla.org/mozilla/source/dom/src/base/nsDOMClassInfo.cpp.
>>
>>/be
> 
> 
> 

-- 
jst

.