Name Description Size
BackstagePass.h 1523
ExportHelpers.cpp stopAtWindowProxy = 18615
JSServices.cpp allowNativeWrapper 5470
JSServices.h 484
README see 40
Sandbox.cpp The Components.Sandbox object. 69835
SandboxPrivate.h 2773
XPCCallContext.cpp Call context. 5653
XPCComponents.cpp The "Components" xpcom objects for JavaScript. 83429
XPCConvert.cpp Data conversion between native and JavaScript types. 49088
XPCDebug.cpp 1653
XPCException.cpp An implementaion of nsIException. 2058
XPCForwards.h Private forward declarations. 1333
XPCInlines.h private inline methods (#include'd by xpcprivate.h). 10573
XPCJSContext.cpp Per JSContext object 52721
XPCJSID.cpp An xpcom implementation of the JavaScript nsIID and nsCID objects. 22003
XPCJSMemoryReporter.h 1030
XPCJSRuntime.cpp Per JSRuntime object 121404
XPCJSThreadPool.h Since XPCOM thread pools dispatch nsIRunnable*, we want a way to take the specific job that JS wants to dispatch offthread, and run it via an nsIRunnable(). RunnableTasks should self-destroy. 1691
XPCJSWeakReference.cpp 2736
XPCJSWeakReference.h 805
XPCLocale.cpp JS locale callbacks implemented by XPCOM modules. These are theoretically safe for use on multiple threads. Unfortunately, the intl code underlying these XPCOM modules doesn't yet support this, so in practice XPCLocaleCallbacks are limited to the main thread. 4732
XPCLog.cpp Debug Logging support. 1854
XPCLog.h Debug Logging support. 2074
XPCMaps.cpp Private maps (hashtables). 9019
XPCMaps.h Private maps (hashtables). 11346
XPCModule.cpp 551
XPCModule.h Module implementation for the xpconnect library. 947
XPCRuntimeService.cpp This will #undef the above 5132
XPCShellImpl.cpp for isatty() 43130
XPCString.cpp Infrastructure for sharing DOMString data with JSStrings. Importing an nsAString into JS: If possible (GetSharedBufferHandle works) use the external string support in JS to create a JSString that points to the readable's buffer. We keep a reference to the buffer handle until the JSString is finalized. Exporting a JSString as an nsAReadable: Wrap the JSString with a root-holding XPCJSReadableStringWrapper, which roots the string and exposes its buffer via the nsAString interface, as well as providing refcounting support. 4400
XPCThrower.cpp Code for throwing errors into JavaScript. 4502
XPCVariant.cpp nsIVariant implementation for xpconnect. 23381
XPCWrappedJS.cpp Class that wraps JS objects to appear as XPCOM objects. 21766
XPCWrappedJSClass.cpp Sharable code and data for wrapper around JSObjects. 39000
XPCWrappedJSIterator.cpp 2732
XPCWrappedNative.cpp Wrapper object for reflecting native xpcom objects into JavaScript. 61625
XPCWrappedNativeInfo.cpp Manage the shared info about interfaces for use by wrappedNatives. 20787
XPCWrappedNativeJSOps.cpp JavaScript JSClasses and JSOps for our Wrapped Native JS Objects. 38889
XPCWrappedNativeProto.cpp Shared proto object for XPCWrappedNative. 4432
XPCWrappedNativeScope.cpp Class used to manage the wrapped native objects within a JS scope. 17400
XPCWrapper.cpp 2424
XPCWrapper.h 980
components.conf 632
jsshell.msg 539 1644
nsXPConnect.cpp High level class and public functions implementation. 36285
xpc.msg 22077
xpcObjectHelper.h 1829
xpcprivate.h XPConnect allows JS code to manipulate C++ object and C++ code to manipulate JS objects. JS manipulation of C++ objects tends to be significantly more complex. This comment explains how it is orchestrated by XPConnect. For each C++ object to be manipulated in JS, there is a corresponding JS object. This is called the "flattened JS object". By default, there is an additional C++ object involved of type XPCWrappedNative. The XPCWrappedNative holds pointers to the C++ object and the flat JS object. All XPCWrappedNative objects belong to an XPCWrappedNativeScope. These scopes are essentially in 1:1 correspondence with JS compartments. The XPCWrappedNativeScope has a pointer to the JS compartment. The global of a flattened JS object is one of the globals in this compartment (the exception to this rule is when a PreCreate hook asks for a different global; see nsIXPCScriptable below). Some C++ objects (notably DOM objects) have information associated with them that lists the interfaces implemented by these objects. A C++ object exposes this information by implementing nsIClassInfo. If a C++ object implements nsIClassInfo, then JS code can call its methods without needing to use QueryInterface first. Typically, all instances of a C++ class share the same nsIClassInfo instance. (That is, obj->QueryInterface(nsIClassInfo) returns the same result for every obj of a given class.) XPConnect tracks nsIClassInfo information in an XPCWrappedNativeProto object. A given XPCWrappedNativeScope will have one XPCWrappedNativeProto for each nsIClassInfo instance being used. The XPCWrappedNativeProto has an associated JS object, which is used as the prototype of all flattened JS objects created for C++ objects with the given nsIClassInfo. Each XPCWrappedNativeProto has a pointer to its XPCWrappedNativeScope. If an XPCWrappedNative wraps a C++ object with class info, then it points to its XPCWrappedNativeProto. Otherwise it points to its XPCWrappedNativeScope. (The pointers are smooshed together in a tagged union.) Either way it can reach its scope. An XPCWrappedNativeProto keeps track of the set of interfaces implemented by the C++ object in an XPCNativeSet. (The list of interfaces is obtained by calling a method on the nsIClassInfo.) An XPCNativeSet is a collection of XPCNativeInterfaces. Each interface stores the list of members, which can be methods, constants, getters, or setters. An XPCWrappedNative also points to an XPCNativeSet. Initially this starts out the same as the XPCWrappedNativeProto's set. If there is no proto, it starts out as a singleton set containing nsISupports. If JS code QI's new interfaces outside of the existing set, the set will grow. All QueryInterface results are cached in XPCWrappedNativeTearOff objects, which are linked off of the XPCWrappedNative. Besides having class info, a C++ object may be "scriptable" (i.e., implement nsIXPCScriptable). This allows it to implement a more DOM-like interface, besides just exposing XPCOM methods and constants. An nsIXPCScriptable instance has hooks that correspond to all the normal JSClass hooks. Each nsIXPCScriptable instance can have pointers from XPCWrappedNativeProto and XPCWrappedNative (since C++ objects can have scriptable info without having class info). 98583
xpcpublic.h 27978