* * *
Bug 772365, Part 2.1: Generate test cases for signed app signature verification
* * *
Bug 772365, Part 2.2: Test JAR signature verification
--HG--
extra : rebase_source : 198be789e8b1565dad418e15760fa6dc90da843f
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.
