XPCOM Tests

An XPCOM object is simply a reference to a library which isn't automatically imported into JS. In order to handle the numerous test cases regarding XPCOM security and compatibility, we simply emulate the behavior of the import facilities that happen in actual Spidermonkey-driven software.

Components.classes is a global entity which has xpcom_wildcard enabled. This means that any time a member of classes is requested and that member doesn't exist, a reference back to classes is returned. This means that things like:

Components.classes.foo.bar.createInstance;
Components.classes.foo.bar.blah.blah.blah.createInstance;
Components.classes.createInstance;

will all return the same thing (the entity for Components.classes.createInstance), assuming that the member being requested is defined. This enables the more complex means of accessing createInstance and getService to all trace back to two entities.

All of the namespaces in Components.interfaces have a special entity property which links them to their respective XPCOM intefaces ("xpcom_map"). When one of the interfaces is passed as a parameter to Components.classes.createInstance or Components.classes.getService, the xpcom_map property will be evaluated and that new global entity will be returned. For instance:

var x = Components.interfaces.nsIWindowMediator;
// `x` has no members

var xpc = Components.classes.createInstance(x);
// `xpc` now has the member `registerNotification`

Ci, Cu, and Cc

All three of the shortcut classes (Ci, Cu, and Cc) are fully and properly implemented. They work by using the "value" parameter to link to the various Components classes.