Subj : Re: the native() call... To : netscape.public.mozilla.jseng From : Oystein Date : Wed Jun 16 2004 07:30 pm Thanks a lot Johnny! It seems to work, but for some reason two function calls that are not part of the executing javascripts are also getting logged: preventBubble and Platform... I dont know why these are called all the time... any idea? And this sentence is a bit unclear to me: >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 Is it possible to access a method without calling it? And just to recap: If I understand it correctly all method and function calls from the executing javascript to the DOM will be handeled by either XPC_WN_CallMethod() or XPC_WN_GetterSetter(), unless the method call is taken care of by nsDOMClassInfo. Is there any good place to find out which methods that nsDOMClassInfo takes care of, without looking through a lot of source code. You mentioned three methods, but I think there are more. For example |document.location = "somewhere";| will not call XPC_WN_GetterSetter(). Again, thanks for the help! Oystein "Johnny Stenback" wrote in message news:40CFE031.8010909@mozilla.org... > 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" 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 .