It's apparently incorrect to return an unwrapped (i.e., xray-waived) object to content, and this is causing the browser frame tests to fail with compartment per global. If that doesn't make sense, perhaps a patch will clear it up.

Comment on attachment 612294 [details] [diff] [review] Patch v1 >Bug 742448 - Don't return xray-waived objects in BrowserElementAPI, and don't use the parent window's content-overridable top property for implementing window.top. >+ // This shouldn't happen, but in case it does, returning this window is >+ // better than throwing. >+ return win; I think we should throw here, or at least somehow make the issue known. >diff --git a/dom/tests/mochitest/browser-frame/test_browserFrame8.html b/dom/tests/mochitest/browser-frame/test_browserFrame8.html >+https://bugzilla.mozilla.org/show_bug.cgi?id=725796 Wrong bug number here, and elsewhere in the file. r=bholley. Thanks for taking care of this so quickly. :-)

> I think we should throw here, or at least somehow make the issue known. Do we have any means of making it known without throwing in release builds? I'm worried that we'll somehow not wrap the parent, or there will be a race condition where the child gets wrapped before the parent, or something...

(In reply to Justin Lebar [:jlebar] from comment #3) > > I think we should throw here, or at least somehow make the issue known. > > Do we have any means of making it known without throwing in release builds? Not sure. > I'm worried that we'll somehow not wrap the parent, or there will be a race > condition where the child gets wrapped before the parent, or something... Sure. But those are things we need to catch. They're still incorrect. It's not clear to me that getting an incorrect window.top is all that much preferable to throwing. At least the developers know that it's Mozilla's fault rather than theirs. Anyway, cjones can make the call here.

> I'm worried that we'll somehow not wrap the parent, or there will be a race condition where the > child gets wrapped before the parent, or something... Heck, let's just throw for now, and we can always change it later. This kind of thing shouldn't happen, and I agree, we should fail loudly, especially while we're in testing.

How does DOMError(INVALID_STATE_ERR) sound?

Actually, doesn't look like I can throw a DOMException from chrome. Is new Error() ok with you?

Use new Error().

Comment on attachment 612333 [details] [diff] [review] Patch v2 Fine by me.

Fixed for FF14: https://hg.mozilla.org/integration/mozilla-inbound/rev/563c26d0a991