dom/interfaces/svg/Makefile.in and dom/media/Makefile.in had merge
conflicts. They were resolved by hand. The former needed 2 IDLs removed.
The latter had a context conflict for EXPORTS_NAMESPACES.
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.
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.
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.
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. :-(
We tack these onto the tests from bug 812415, adding coverage for
nsExpandedPrincipal and making sure that the waivers are deep.
We also take the opportunity to check the asymmetric security
relationship between a principal and its corresponding nsEP.
This adds support for many kinds of Paris bindings objects as weak map keys.
This patch supports nsISupports objects as well as non-cycle-collected
non-nsISupports objects. What is needed for support is to preserve any wrapper,
if the object is wrapper cached. In other cases, we don't need to do anything.
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.
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.
