Changes

Jump to: navigation, search

Labs/Jetpack/JEP/25

1,447 bytes added, 01:32, 15 September 2009
added another example, reworded some sstuff
* They have the ability to register callbacks that perform cleanup tasks when unloaded.
* They have full access to XPConnect's <tt>Components</tt> object, and all its sub-objects.
* When used in a XULRunner extension, they should be equally at home in both a chrome-privileged page/window and a JS module.
For security purposes, Chrome Boosters can only be accessed either
This code doesn't actually work; it's just aspirational.
=== XULRunner Extensionextension, in a Chromechrome-privileged page /window ===
Assume that the following code is contained in a file at <tt>chrome://some_extension/content/foo.html</tt>.
Note that the <tt>unload</tt> module conventions are laid out by the [http://narwhaljs.org/narwhal.html Narwhal] CommonJS-based platform.
 
=== XULRunner extension, in a JS module ===
 
Chrome Booster functionality should be just as easy to access if the
calling code is in a JS module instead of a page. As such,
<tt>securable-module.js</tt> is engineered to detect which context
it's loaded in and "just work" accordingly:
 
<pre>
// The same file we loaded in-page in the last example can actually be
// loaded as a JS module, too:
var SecurableModule = {};
Components.utils.import("resource://some_extension/content/securable-module.js",
SecurableModule);
 
// Create a loader for SecurableModules that gives them chrome
// privileges by default and roots the filesystem at
// chrome://some_extension/content/lib/. We can't provide a
// relative directory name here because JS modules don't conventionally
// have a concept of relative directories (and we won't introduce such
// a concept here to reduce potential confusion).
var loader = SecurableModule.Loader({
defaultPrincipal: "system",
rootPath: "chrome://some_extension/content/lib"
});
 
// Load the 'foo' SecurableModule and call its exported doSomething()
// function.
loader.require('blarg').doSomething();
</pre>
 
Note that while we could unload the module if we want, we don't really
have any pressing reason to, since JS modules themselves are never
unloaded.
874
edits

Navigation menu