There are a number of fixes to this important tests, so this warrants a separate
patch.
First of all, the boundTo machinery goes away, because we no longer have same-
compartment Xrays giving us the weird bound methods.
Furthermore, now that the sensitive methods are just regular old methods
off the prototype. They'll fail correctly when used on a same-scope object,
but not for cross-scope XOWs they'll just fail in the
GetWrappedNativeOfJSObject rat's nest (when they can't unwrap the security
wrapper), so we'll just get a generic XPConnect error instead of a security
exception. I want to fix this soon, so I changed the skipMessageCheck stuff
to use todo_is.
However, _that_ caused an UNEXPECTED-PASS for the DefaultValue test (which
was the only one of the array of tests that was throwing a security exception
in step 2). So I added an annotation for that in item[2].
Removing test coverage isn't great. But the only reason this test is doing all
this funny stuff with Location is that it thinks that it's always wrapped in
an Xray wrapper and that we always do a dynamic security check, which is no
longer true. Moreover, it checks for very specific error messages, which are
kind of in flux right now as I'm fixing up GWNOJO. The calls are never going
to actually succeed (since location isn't a Node), so it's not really clear
how to fix up this test to do something uniquely useful in a readable way.
I've added enough Location test coverage recently that I'm comfortable removing
this part.
This allows us to remove the same-compartment Location wrappers. This can
go away when we move Location to the new bindings and get access to
[Unforgeable].
We have a very nice and robust infrastructure for per-origin expando sharing
for Xrays. Unfortunately, the only way to currently exercise it is with
Location objects, since those are the only objects with same-origin Xrays
(cross-origin Xrays don't allow expandos at all). Sandbox wantXrays would
almost work here, but we actually make an explicit exception for sandboxes
so that they never share expandos (the 'exlusive global' stuff).
I think the infrastructure is nice and that we may want it in the future, so
I don't really want to back it out. But I also don't want to leave it in the
tree untested. So I'm adding an explicit Cu API to force DOM compartments to
use same-origin Xrays. This allows us to keep testing this stuff, which I think
is important.
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.
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.
There is no reason to have special methods for specific sets of CompileOptions
when the JS::Compile interface is so easy to use. Other API methods can be
moved internal or removed entirely with this change.
--HG--
extra : rebase_source : f48fb221ebe02c0137e521ea605953532808825d
This is a pretty dumb bug, but we never actually hit this codepath at the moment.
We currently end up in wrapper by either explicitly calling
ReparentWrappedNativeIfFound (in nsNodeUtils and in nsHTMLDocument), or by moving
existing wrappers during orphan fixup. The former always passes a wrapper-cached
object, and the latter guarantees that we always have a wrapper. So we'd never
hit the "no wrapper cache, no wrapper" case in the current 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.
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 have many CESU8 paths in SpiderMonkey which are completely unused and
untested. We have many more "UTF-8" paths which are really mislabled CESU8 paths
and visa-versa. This patch attempts to disentable all of the various encoding
options in SpiderMonkey.
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.
xpc_NewSystemInheritingJSObject is totally unnecessary now that the system bit
has been removed (\o/). Furthermore, the mJSPrototypeObject optimization is
really dumb. it complicates tracing significantly, and we don't actually use it
in any critical places: XPCWrappedNative and slim wrapper creation use a different
prototype, so this is used only for the creation of tearoff reflectors (seldom/
never used), XPCWrappedNativeProto objects, and the nohelper prototype on the
scope (once per scope).
We could actually just pass NULL to JS_NewObject and let it deal. However, this
would actually trigger a dynamic lookup for the prototype object of the
associated JSClass, which isn't what we want. So we just explicitly pass in
Object.prototype.
We already weren't creating a scope for them. They're generally pretty isolated
and are just used for holding functions that get cloned into other scopes.
Apparently mccr8 once found an edge from an nsXULPrototypeDocument scope into
another scope, but I don't think that should really break anything.
The compartment set goes away in later patches anyway. This is to allow us to
create compartment privates for things like XUL prototype document globals
without having to put them in the set and trace expandos and such.