require("chrome")
Brian Warner
generation" work I've been poking at (see bug 572020 for more details).
The biggest consequence of this patch is that any "chrome-authority"
modules, i.e. those that need to use Components.classes or
Components.interfaces, etc, must change the way they get access to these
powerful objects. Previously, the usual Cc/Ci aliases were pre-loaded
into the global namespace of all Jetpack modules, and the "Components"
object was ambiently available as well.
With this change, the aliases are no longer pre-loaded, and the raw
"Components" object is off-limits. Modules that need e.g. Cc/Ci should
obtain them as follows:
var {Cc, Ci} = require("chrome");
(this uses the "destructuring assignment" feature available in
spidermonkey, so don't go trying this sort of thing in other JS
environments).
require("chrome") is a special case of require(): there is no actual
chrome.js file. It provides an object with Cc,Ci,Cu,Cr,Cm aliases and a
(lowercase) "components" object to replace the raw (uppercase)
"Components" object.
There is now code in the "cfx xpi" path that scans modules for uses of
Components, or of Cc/Ci/etc without a corresponding require("chrome")
call, and will complain about it, with instructions of what you should
do instead.
In addition, the "cfx xpi" codepath also builds a "manifest" that writes
down which modules import which other modules, as well as which modules
use chrome authority.
The reason for this change is to keep closer track of which modules want
to use chrome authority. It will take some time to implement all the
security-improving pieces, but the general idea is that manifest will
record intentions ("I want to use chrome authority"), some reviewers
will evaluate the manifest ("yeah, that's ok"), and the runtime loader
will enforce the manifest ("the manifest says ok, otherwise your
require() fails"). A module which does not politely ask for permission
ahead of time will not be able to sneakily acquire access later on.
I've updated all the modules that live in the SDK to use the new
pattern, but any chrome-using modules that you're working on outside of
current trunk will need to be updated. Also, any unit-test modules that
use Cc/Ci will need the same. Use "cfx testall -a firefox" to discover
which modules are lacking: there is a unit test that scans everything in
jetpack-core for compliance. Also, using "cfx xpi" to build any add-on
will scan all the modules that it copies into the XPI file, which will
also tell you about the ones that are missing require("chrome").
Hopefully this won't cause too many problems. Please let me know if you
run into trouble or see anything weird.
cheers,
-Brian