| components.conf |
|
543 |
- |
| ExecutionTracerIntegration.cpp |
|
6779 |
35 % |
| ExecutionTracerIntegration.h |
ExecutionTracerIntegration_h_ |
3852 |
- |
| ExportHelpers.cpp |
stopAtWindowProxy = |
18760 |
84 % |
| JSServices.cpp |
allowNativeWrapper |
5273 |
90 % |
| JSServices.h |
|
398 |
- |
| jsshell.msg |
Error messages for JSShell. See js/public/friend/ErrorNumbers.msg for format.
|
464 |
- |
| moz.build |
|
2039 |
- |
| nsIXPConnect.h |
The core XPConnect public interfaces. |
9460 |
100 % |
| nsXPConnect.cpp |
High level class and public functions implementation. |
39636 |
89 % |
| README |
see http://www.mozilla.org/scriptable |
40 |
- |
| Sandbox.cpp |
The Components.Sandbox object.
|
82845 |
86 % |
| SandboxPrivate.h |
|
4848 |
92 % |
| SystemGlobal.h |
|
3173 |
88 % |
| xpc.msg |
Error Message definitions. |
23908 |
- |
| XPCCallContext.cpp |
Call context. |
5496 |
85 % |
| XPCComponents.cpp |
The "Components" xpcom objects for JavaScript. |
81038 |
80 % |
| XPCConvert.cpp |
Data conversion between native and JavaScript types. |
47803 |
82 % |
| XPCDebug.cpp |
|
1534 |
75 % |
| XPCException.cpp |
An implementaion of nsIException. |
1961 |
90 % |
| XPCForwards.h |
Private forward declarations. |
1146 |
- |
| XPCInlines.h |
private inline methods (#include'd by xpcprivate.h). |
10451 |
96 % |
| XPCJSContext.cpp |
Per JSContext object |
54675 |
86 % |
| XPCJSID.cpp |
An xpcom implementation of the JavaScript nsIID and nsCID objects. |
21660 |
88 % |
| XPCJSMemoryReporter.h |
|
953 |
- |
| XPCJSRuntime.cpp |
Per JSRuntime object |
131144 |
86 % |
| XPCJSWeakReference.cpp |
|
2615 |
88 % |
| XPCJSWeakReference.h |
|
646 |
100 % |
| 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.
|
4299 |
96 % |
| XPCLog.cpp |
Debug Logging support. |
1773 |
- |
| XPCLog.h |
Debug Logging support. |
1947 |
- |
| XPCMaps.cpp |
Private maps (hashtables). |
6060 |
98 % |
| XPCMaps.h |
Private maps (hashtables). |
10221 |
91 % |
| XPCModule.cpp |
|
430 |
100 % |
| XPCModule.h |
Module implementation for the xpconnect library. |
736 |
- |
| xpcObjectHelper.h |
|
1710 |
100 % |
| 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).
|
97304 |
96 % |
| xpcpublic.h |
|
32756 |
90 % |
| xpcrtfuzzing |
|
|
- |
| XPCRuntimeService.cpp |
This will #undef the above |
7550 |
80 % |
| XPCSelfHostedShmem.cpp |
|
3100 |
96 % |
| XPCSelfHostedShmem.h |
|
3301 |
100 % |
| XPCShellImpl.cpp |
for isatty() |
43076 |
60 % |
| 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.
|
1584 |
100 % |
| XPCThrower.cpp |
Code for throwing errors into JavaScript. |
4373 |
92 % |
| XPCVariant.cpp |
nsIVariant implementation for xpconnect. |
22897 |
65 % |
| XPCWrappedJS.cpp |
Class that wraps JS objects to appear as XPCOM objects. |
22688 |
91 % |
| XPCWrappedJSClass.cpp |
Sharable code and data for wrapper around JSObjects. |
37584 |
84 % |
| XPCWrappedJSIterator.cpp |
|
2598 |
89 % |
| XPCWrappedNative.cpp |
Wrapper object for reflecting native xpcom objects into JavaScript. |
62134 |
89 % |
| XPCWrappedNativeInfo.cpp |
Manage the shared info about interfaces for use by wrappedNatives. |
20959 |
89 % |
| XPCWrappedNativeJSOps.cpp |
JavaScript JSClasses and JSOps for our Wrapped Native JS Objects. |
39368 |
86 % |
| XPCWrappedNativeProto.cpp |
Shared proto object for XPCWrappedNative. |
4423 |
93 % |
| XPCWrappedNativeScope.cpp |
Class used to manage the wrapped native objects within a JS scope. |
16724 |
93 % |
| XPCWrapper.cpp |
|
2464 |
93 % |
| XPCWrapper.h |
|
857 |
- |