Now that XBL scopes are here to stay (no more pref), we can remove all the
machinery that makes SOWs dynamic. We still need SOWs until bug 825392 is
fixed, but they can now be totally opaque.
One side effect of this patch is that, due to our usage of Opaque, we now
allow CALL on SOWs. But this shouldn't be a problem, because SOWs are used
for anonymous elements which are not callable (and we probably wouldn't mind
it even if they were).
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. :-(
__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.
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.
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.
