Switch from using the interface objects from the Xrays compartment to wrapping
interface objects and interface prototype objects in Xrays. Make dom binding
Xrays deal with both instance objects and interface and interface prototype
objects.
This change means we no longer have to keep around a set of XPConnect compartments.
We keep the compartment private around for non-xpconnecty stuff like about:memory
instrumentation that needs to happen on non-xpconnect compartments.
We don't currently have a good way of selecting the traits used by a given Xray
wrapper. This lets us do that.
Note: We add a call to js::UnwrapObject to GetXrayType while hoisting it. When
it was used only in WrapperFactory, this was unnecessary, because |obj| was
always unwrapped. But for our new purposes, it might not be. Aside from that,
there are no changes to the function.
With this patch, all holders are created lazily. There are two common accessors,
getHolder() and ensureHolder(). The former returns null if no holder exists, the
latter lazily creates the holder if it doesn't exist. It does this by calling into
a virtual trap on XrayTraits, which lets the appropriate Xray type do its thing.
We currently set this for system globals and anything whose parent
chain leads to a system global. Maybe this was relevant before, but
with CPG this is just equivalent to asking whether the object is in
a system compartment. And the only place where we _check_ this bit
is immediately after checking for a system compartment, in
WrapperFactory. So AFAICT this can go away entirely.
We currently set this for system globals and anything whose parent
chain leads to a system global. Maybe this was relevant before, but
with CPG this is just equivalent to asking whether the object is in
a system compartment. And the only place where we _check_ this bit
is immediately after checking for a system compartment, in
WrapperFactory. So AFAICT this can go away entirely.
This can happen if chrome sets its proto to a content object from a different scope
than the one doing the wrapping. In this case, the prototype chain looks like this:
chromeobj => CCW(examplecom_obj) => CCW(examplecom_scope.Object.prototype)
When wrapping chromeobj for exampleorg_scope, things will look like this:
COW(chromeobj) => CCW(examplecom_obj) => CCW(examplecom_scope.Object.prototype)
Note that we don't remap the proto of CCW(examplecom_scope) to
exampleorg_scope.Object.prototype, because the proto remapping only happens when
the object we're wrapping is chrome. There's no reason it has to be this way, but
even if we changed it we still wouldn't get the nice remapped lookup behavior to
exampleorg_scope.Object.prototype, because the proxy handler for CCW(examplecom_obj)
isn't a ChromeObjectWrapper, and thus doesn't know how to to the prototype bouncing
correctly.
Anyway, I suspect this case isn't worth worrying about as long as we don't crash.
Now that we have nsExpandedPrincipal, the current way of doing things is wrong. For some reason, the old document.domain hackery was hiding the failures here.
In the new setup, all per-interface DOM binding files are exported into
mozilla/dom. General files not specific to an interface are also exported into
mozilla/dom.
In terms of namespaces, most things now live in mozilla::dom. Each interface
Foo that has generated code has a mozilla::dom::FooBinding namespace for said
generated code (and possibly a mozilla::bindings::FooBinding_workers if there's
separate codegen for workers).
IDL enums are a bit weird: since the name of the enum and the names of its
entries all end up in the same namespace, we still generate a C++ namespace
with the name of the IDL enum type with "Values" appended to it, with a
::valuelist inside for the actual C++ enum. We then typedef
EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to
refer to the values, but means that values from different enums don't collide
with each other.
The enums with the proto and constructor IDs in them now live under the
mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively.
Again, this lets us deal sanely with the whole "enum value names are flattened
into the namespace the enum is in" deal.
The main benefit of this setup (and the reason "Binding" got appended to the
per-interface namespaces) is that this way "using mozilla::dom" should Just
Work for consumers and still allow C++ code to sanely use the IDL interface
names for concrete classes, which is fairly desirable.
--HG--
rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp
rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
