We have a number of Mochitests that rely on violating cross-origin checks. For example: These all use the feed parser, which apparently winds up not same-origin: http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/test_bug364677.html?force=1 http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/test_bug395533.html?force=1 http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/test_bug395533.html?force=1 http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/test/test_bug408328.html?force=1 http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/test/test_bug494328.html?force=1 Cross origin XHR: http://mxr.mozilla.org/mozilla-central/source/content/base/test/test_bug431701.html?force=1 I don't know if there's an easy way to translate these to using a SpecialPowers API, or if they should just all wind up as chrome Mochitests.

Jonas: bug 641706 should fix the XHR issues (which I think will be very useful). A bunch of these other tests want to touch the DOM of a cross-origin document. Is that something we can fix, or should we just be moving these tests into mochitest-chrome?

We could add a bunch of SpecialPowers APIs which allow poking at various cross-site nodes. However I suspect the solution would be fairly complex if we want to expose arbitrary poking. So if we can rewrite to use mochitest-chrome then that might be better. One alternative would be to allow running XPath expressions that return non-nodes. Something like SpecialPowers = { ... runXPathExpression(expr, window) { res = window.document.evaluate(expr, window.document, null, window.XPathResult.ANY_TYPE, null); switch(res.resultType) { case res.NUMBER_TYPE: return res.numberValue; case res.STRING_TYPE: return res.stringValue; cast res.BOOLEAN_TYPE: return res.booleanValue; default: throw "Wrong Type"; } } ... }; It *should* also be possible to use javascript proxies in combination with wrapper magic to create a wrapper which allows exposing the full DOM cross site. If someone wants to look into that then that is an option.

Oh, the XPath idea sounds like a good one! I'm not terribly familiar with XPath, but I feel like all the feedparser tests could certainly be switched to use that. It feels like a fair tradeoff that doesn't require us to implement complex security checks, but still exposes a pretty flexible API.

Blake says we can probably write a JS proxy that can be requested through SpecialPowers, which can then give access to whatever the page normally doesn't have access to, etc. He'll write something up and we'll see if that covers all we need here...

This was fixed by bholley a while ago.