Last Comment Bug 688776 - test_doublewrappedcompartments.xul relies on XHR event listener being an nsIDOMEventListener
: test_doublewrappedcompartments.xul relies on XHR event listener being an nsID...
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla10
Assigned To: Kyle Huey [:khuey] (
Depends on:
Blocks: 687332
  Show dependency treegraph
Reported: 2011-09-23 09:56 PDT by Kyle Huey [:khuey] (
Modified: 2011-09-29 09:17 PDT (History)
1 user (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (2.37 KB, patch)
2011-09-26 15:22 PDT, Kyle Huey [:khuey] (
mrbkap: review+
Details | Diff | Splinter Review

Description Kyle Huey [:khuey] ( 2011-09-23 09:56:14 PDT
test_doublewrappedcompartments.xul expects that if it sets and then retrieves the onreadystatechange event handler on an XHR object that it will receive a wrapped nsIDOMEventListener.  After Bug 687332 this is no longer the case.

I'm not really sure what do to with this one, since it's not clear to me what it's testing.  Blake?
Comment 1 Blake Kaplan (:mrbkap) 2011-09-26 13:32:51 PDT
The test is making sure that if chrome JS gets its hands on a double wrapped JS object (that usually means a component implemented in JS that gets re-exposed to JS through XPConnect) and then passes that double-wrapped JS object to content, then content gets another double wrapped JS object instead of a security wrapper around chrome's double wrapped JS object. When I wrote this test (as well as a couple of the other tests that you've filed bugs on in the past week) the easiest way to get my hands on a double wrapped JS object was via event handlers. Is there a nicer way to get a double wrapped object?
Comment 2 Kyle Huey [:khuey] ( 2011-09-26 15:22:40 PDT
Created attachment 562554 [details] [diff] [review]

So, this is all dark magic to me, but it's worth noting that I have to retrieve iter.filter in the content scope to get this test to pass.  If I retrieve iter.filter in the chrome scope I get a standard double-wrapped object with no proxy.

That may or may not be the expected behavior here ...
Comment 3 Blake Kaplan (:mrbkap) 2011-09-26 15:25:37 PDT
Comment on attachment 562554 [details] [diff] [review]

Yeah, this is fine.

>+++ b/js/src/xpconnect/tests/chrome/test_doublewrappedcompartments.xul
>@@ -25,20 +25,20 @@
>-        ok(unwrapped.testme(readystatechange),
>+        ok(unwrapped.testme(filter),
>            'content didn\'t get a proxy, but another double wrapped object');

While you're here, mind changing this to use double quotes around the outside to avoid having to escape the apostrophe in didn't?

r=me either way.
Comment 4 Kyle Huey [:khuey] ( 2011-09-29 09:17:29 PDT

Note You need to log in before you can comment on or make changes to this bug.