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.
Bobby Holley
Bill McCloskey
Peter Van der Beken
Terrence Cole
Boris Zbarsky
Fernando Jiménez
Benoit Jacob
Nathan Froyd
Kannan Vijayan
Andrea Marchesini
Ehsan Akhgari
Ms2ger
Ed Morley
Nicholas Nethercote
Kyle Huey
Tom Schuster
Vicamo Yang
Andrew McCreight
Jonas Sicking
Jacek Szpot
Ryan VanderMeulen
Andrew Quartey
Nikhil Marathe
Olli Pettay
Benjamin Peterson
Chuck Lee