This method is larely deprecated. The only two consumers are JSD and the setup
for the safe JSContext, neither of which use system principal and thus neither
of which should have |Components|.
The patch removes no longer used XPCJSRuntime::mJSCycleCollectionContext,
nsXPConnect::mCycleCollectionContext and related code to create/destroy
contexts. As that made nsCycleCollectionJSRuntime::FinishTraverse() empty
in all cases I removed that method as well.
The behavior here is a bit weird because Document is still not a
WebIDL object, so calling createNodeIterator or createTreeWalker via
an Xray will call the XPCOM versions of those methods. That means
that I can't just disable XPCOM-based wrapping for TreeWalker and
NodeIterator altogether, unfortunately, which means a web page could
try stashing a TreeWalker in something like userdata and then getting
it back and end up wrapping it as an XPCOM object the second time.
I could "fix" that by adding a wrapper cache and whatnot, I guess, if
desired... But the problem will go away once we convert Document in
any case.
This does allow people to accidentally hit the slower path through use
of non-const strings, but I think that's OK now that we're mostly
autogenerating this stuff
The behavior here is a bit weird because Document is still not a
WebIDL object, so calling createNodeIterator or createTreeWalker via
an Xray will call the XPCOM versions of those methods. That means
that I can't just disable XPCOM-based wrapping for TreeWalker and
NodeIterator altogether, unfortunately, which means a web page could
try stashing a TreeWalker in something like userdata and then getting
it back and end up wrapping it as an XPCOM object the second time.
I could "fix" that by adding a wrapper cache and whatnot, I guess, if
desired... But the problem will go away once we convert Document in
any case.
This does allow people to accidentally hit the slower path through use
of non-const strings, but I think that's OK now that we're mostly
autogenerating this stuff
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.
We leave the nsIDOMEventTarget* versions fallible for now, but this makes the
common case a lot simpler. Note that this means that pushing a null JSContext,
a bug, is no longer handled at runtime. But I think we should just assert
against it, since there are already callers that don't check the return value.
The goal here is to get rid of this crap entirely, and make nsCxPusher always
push. But that's a scary change, so we do it in chunks. This patch, in particular,
should have zero behavioral change. This means preserving some very wrong behavior.
For instance, currently SafeAutoJSContext never pushes a damn thing, because the
safe JSContext doesn't have an associated nsIScriptContext. We preserve this
behavior, and in fact convert various similarly-buggy consumers to
SafeAutoJSContext, so that we can hoist the behavioral change into a subsequent
patch.
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.
