This is just a heuristic, anyway, and some of the usage is downright broken.
There are two cases here:
1 - Deciding what to do for get{Own,}PropertyDescriptor. In these cases, we can
just enter with GET and rely on the filtering machinery to filter out dangerous
setters for security wrappers.
2 - Custom Xray props. None of these make sense in a |set| context. In fact,
they generally have null setters anyway, so we can just assume GET.
The policy-entering code in XrayWrapper is super haphazard. We'll get rid of it
entirely later in these patches.
This is just a heuristic, anyway, and some of the usage is downright broken.
There are two cases here:
1 - Deciding what to do for get{Own,}PropertyDescriptor. In these cases, we can
just enter with GET and rely on the filtering machinery to filter out dangerous
setters for security wrappers.
2 - Custom Xray props. None of these make sense in a |set| context. In fact,
they generally have null setters anyway, so we can just assume GET.
The policy-entering code in XrayWrapper is super haphazard. We'll get rid of it
entirely later in these patches.
The naming scheme for Xray typedefs is the concatenation of the tuple:
({SC,}, {Security,Permissive}, Xray, {XPCWN,DOM}). This is admittedly a bit
much, but I think it's still better than explicitly doing the "typdef Foo Xray"
everywhere. Moreover, once the new DOM bindings are done, the last component
in the tuple will go away.
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.
We do this for delete_, enumerateNames, and resolveOwnProperty. This doesn't change
existing behavior, because for ProxyXrayTraits and DOMXrayTraits the expando object
will (currently) always be null.
For new DOM proxies, we could probably use the Xray expando machinery for the
regular expando object as well, and free up one of the reserved slots. That's
more than I want to bite off for the moment, though.
I also decided not to block on bug 760095 and just kick the problem of globals
with new binding down the road a little bit.
I'm not sure this stuff is correct for non-WN objects. Hopefully that will
come out in review.
Anyway, with this change, the expando infrastructure in XrayTraits is now
fully generic and non-WN-specific. To make things work for other objects,
we now need to implement the virtual traps and hoist the code that calls the
expando machinery out of XPCWrappedNativeXrayTraits.
It's still WN-only, now we can move the WN-only bits into virtual traps.
Note that the new-binding reparenting code will need to have a call to
CloneExpandoChain.
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.
The current name potentially implies that the object returned is an inner
object in the JS sense, which isn't true. Really we just want the thing
we're Xraying to.
There's some code that can be shared between different Xray traits, but can't
(yet) be hoisted into XrayWrapper, because it needs to be callable from outside
XrayWrapper where we don't have the appropriate template parameters. Moreover,
this code benefits from virtual function specialization. The use case here is
illuminated in the next patch.
For the moment, we skip converting the bulk of the traits calls to virtual
methods, because they're working just fine.
We might as well do this dynamically, which simplifies the code. Note that we
could avoid the reserved slot by parenting the holder to the wrapper. But the
JS parent API is deprecated, and we need to move away from it to reserved slots
anyhow. We might as well start here, with the added advantage that parenting
to the global makes us consistent with the other Xray types.
There are really two questions to be asked: is the caller chrome, and does the
caller subsume the callee. We have other, more precise ways of asking both of
these questions.
There are really two questions to be asked: is the caller chrome, and does the
caller subsume the callee. We have other, more precise ways of asking both of
these questions.
There are really two questions to be asked: is the caller chrome, and does the
caller subsume the callee. We have other, more precise ways of asking both of
these questions.
Note: This overloads the naming of some of the existing infrastructure,
but the signatures etc are sufficient to disambiguate. The other infrastructure
goes away in a subsequent patch.
Note: We tag sandbox expandos with their global to make sure that the expandos
are never shared between sandboxes. A consequence of this scheme is that an
expando from a sandbox to an object will _always_ result in a GC edge back to
the sandbox, meaning that the sandbox is always kept alive for the lifetime of
the expando target. This could happen before, but only if a non-primitive expando
was placed (since the value of the expando would live in the consumer's
compartment). We could avoid this edge by using a reference-counted Identity()
object instead, but I suspect it's not worth worrying about.
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
