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 kind of nonsensical, because CALL means "the wrapped object is being
called", whereas nativeCall means "the wrapped object is being unwrapped to
have a JSNative invoked on it", which are two very different things.
We _could_ add a NATIVECALL enter() trap, but our current policy enforcement
around nativeCall involves overriding the trap itself, so we wouldn't use it
for anything. So let's just get rid of it.
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.
