Backed out changeset 1df3bdadb7ce (bug 843829)
Backed out changeset 64f001fe04fb (bug 843829)
Backed out changeset 57652d8f0827 (bug 843829)
Backed out changeset 2e889cd77a48 (bug 843829)
Backed out changeset 97d16e7beb27 (bug 843829)
Backed out changeset 6c6ab0e54917 (bug 845862)
Landed on a CLOSED TREE
There were merges in configure.in and some Makefile.in. None had any
conflicts. I spot verified the Makefile.in changes and confirmed that
the changes did not touch any DIRS* variables.
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.
We update the tests to cover this case. There was also a bug in the tests where
we were accidentally testing non-writable Location properties against window
rather than window.location. :-(
There's no reason to do this any different than we do for XOWs and such. The
only thing this might conceivably support would be certain chrome XPWNs-as-COWs.
But that would require that they forced a parent in precreate without being
flagged as DOM objects in classinfo. And it's not clear why we'd want to support
that. And we're generally moving away from COWs anyway.
__scriptOnly__ is unused on mxr and addons-mxr. Morevoer, the current
implementation is totally broken, because we check for NNXOW, which only
happens when a random content JS object ends up in some other cross-origin
scope (via addons, presumably), whereas chrome objects use ChomeObjectWrapper.
I'm soon going to replace SCRIPT_ACCESS_ONLY with checked unwrapping, and mark
all COWs as unsafe to unwrap (see bug 821573 and bug 658909). So let's just kill
this thing here.
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.
This is another one of those annoying situaitons in XPConnect right now where we
can't ask a question without potentially throwing if the answer is no. There's
also a bunch of unused cruft in here (like the Perm*Access stuff), so this stuff
was ripe for a spring cleaning. Unfortunately, I wasn't able to divide this patch
up nicely. Sorry for the big diff. :-(
In a nutshell, this patch changes things so that Policy::check() just becomes
a predicate that says whether the access is allowed or not. There's the remote
possibility that one of the underlying JSAPI calls in a ::check() implementation
might throw, so callers to ::check() should check JS_IsExceptionPending
afterwards (this doesn't catch OOM, but we can just continue along until the
next OOM-triggering operation and throw there).
Aside from exceptional cases, callers should call Policy::deny if they want to
report the failure. Policy::deny returns success value that should be returned
to the wrapper's consumer.
There's really no reason to use the wishy-washy static COW Deny() here.
Also, note that the xpcshell-test wasn't testing what it thought it
was - interfaces is accessible from content code.
This is another one of those annoying situaitons in XPConnect right now where we
can't ask a question without potentially throwing if the answer is no. There's
also a bunch of unused cruft in here (like the Perm*Access stuff), so this stuff
was ripe for a spring cleaning. Unfortunately, I wasn't able to divide this patch
up nicely. Sorry for the big diff. :-(
In a nutshell, this patch changes things so that Policy::check() just becomes
a predicate that says whether the access is allowed or not. There's the remote
possibility that one of the underlying JSAPI calls in a ::check() implementation
might throw, so callers to ::check() should check JS_IsExceptionPending
afterwards (this doesn't catch OOM, but we can just continue along until the
next OOM-triggering operation and throw there).
Aside from exceptional cases, callers should call Policy::deny if they want to
report the failure. Policy::deny returns success value that should be returned
to the wrapper's consumer.
There's really no reason to use the wishy-washy static COW Deny() here.
Also, note that the xpcshell-test wasn't testing what it thought it
was - interfaces is accessible from content code.
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.
Let's just bite the bullet and do this here. It will let us get rid of
IndirectProxyHandler, which has really overcomplicated our proxy hierarchy.
--HG--
extra : rebase_source : 7e81529936bc256d672e40537eb6abca6374e52c
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 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.
We want this right now so that we can avoid the scary warning when content Components
access happens in XBL (which we're allowing going forward). This patch would be overkill
just for that, but I also have plans to introduce a SOW-like protection of the Components
wrapper filtering policy. I can't just do the filename hack for that though, because real-
world XBL filenames might be all over the place. So let's just be safe here.
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.
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.
Gabor Krizsanits
Ryan VanderMeulen
Jacek Szpot
Ms2ger
Bobby Holley
Ehsan Akhgari
Jon Coppeard
Kyle Machulis
Eddy Bruel
David Zbarsky
Tom Schuster
Mike Shal
Mohit Gahlot
Bill McCloskey
Ed Morley
Gregory Szorc
Phil Ringnalda
Peter Van der Beken
Boris Zbarsky
Jeff Walden
Saurabh Anand
Isaac Aggrey
Andrew Sutherland
Luke Wagner
Matt Brubeck
Mike Hommey
Aryeh Gregor
Brian Hackett