Closed Bug 720714 Opened 10 years ago Closed 9 years ago

"Assertion failure: compartment mismatched" when accessing iframe

Categories

(Core :: XPConnect, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 763225

People

(Reporter: mdas, Unassigned)

References

Details

Attachments

(1 file)

I have a page with an iframe who are both served from the same domain/directory, but whenever I attempt to access the iframe's onload function, I get:

Assertion failure: compartment mismatched, at /Users/mdas/code/mozilla-central/js/src/jscntxtinlines.h:153

I am running the following JS code in the content process:
    content.frames[0].onload = function () { alert("loaded");};

I also tried the following code in a chrome process, and it got the same assertion failure: 
    var win = this.browser.browser.contentWindow;
    win.frames[0].onload = function () { alert("loaded");};

I've run this code with the main page and iframe being served via file:/// in the same directory, and via a local webserver, being hosted from the same port and directory as well, but I still see the assertion error.
I was not able to reproduce with a simple experiment based on the description.  Could you (1) tell us what version you are using (2) attach a test-case and (3) try out the testcase on a trunk build?  Thanks!
(In reply to Luke Wagner [:luke] from comment #1)
> I was not able to reproduce with a simple experiment based on the
> description.  Could you (1) tell us what version you are using (2) attach a
> test-case and (3) try out the testcase on a trunk build?  Thanks!

Sure, I was using the code at this revision https://hg.mozilla.org/mozilla-central/rev/1cfc17f1bd13 

I've been trying, but I can't seem to write a mochitest that shows this error yet. Worse case, I'll load the problematic code in an extension and it should demonstrate the error.
Attached file mochitest chrome test
Here's a test that demonstrates the problem. Drop it in your (objdir)/_tests/testing/mochitest/chrome folder. Run this with 

python runtests.py --chrome --test-path=test_bug720714.xul

Then click the link to the test (chrome://mochitests/content/chrome/test_bug720714.xul) on the test page (Don't press 'run chrome tests'), then the browser will crash and you'll see the assertion failure in the log.

I tested this with trunk and it is reproducible.
Great, I can reproduce, thanks!
Blake/Bobby: nsEventListenerManager::SetJSEventListenerToJsval is hitting a compartment assert when chrome tries to add an event listener to content because the compartment of the context passed to SetJSEventListenerJsval doesn't match the compartment of one of the parameters ('aScope').  Does XPCWN::CallMethod try to make the context match its parameters?  Seems like maybe not.

If not, then it seems like we need an AutoEnterCompartment somewhere in the stack:
 nsEventListenerManager::SetJSEventListenerToJsval
 nsJSUtils::GetStaticScriptContext
 nsJSUtils::GetStaticScriptGlobal (assert in JS_GetGlobalForObject)

Turning this bug over to XPConnect since I'm not sure where the "right" place is.  Another possibility is that (like JS_GetPrivate) JS_GetGlobalForObject shouldn't assert same compartment.
Assignee: general → nobody
Component: JavaScript Engine → XPConnect
QA Contact: general → xpconnect
This is making it hard for us to debug test failures on B2G. Any chance we could get some eyes on this?
The problem as described in comment 5 was fixed in bug 763225, in Firefox 14+ (cc list fail in this bug, I think).  The steps in comment 3 work for me (on trunk, but I could test on beta if you'd like me to).

If you're hitting this problem in b2g tests, I'd like to know how....
Depends on: 763225
This should be s-s.
Group: core-security
This is related to bug 722596.  I didn't realize it was fixed; I'll see if we can use window.onerror in Marionette's b2g sandboxes now.
OK.  I'm going to mark this resolved, since I think it is, but please reopen if there's still a problem here!
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 763225
Group: core-security
You need to log in before you can comment on or make changes to this bug.