To be complete, the unsigned version of the script is directly accessible here: http://www.lowcoders.fr/xul/index.xul
Yeah. The problem is that the signed script and the data gotten via XMLHttpRequest are different origins, since said data doesn't come from inside the signed jar. On trunk, we set the calling document principal on the XMLHttpRequest response (see bug 326337), but that change never landed on branch, so we get this bug.
So this would be fixed by a branch version of the patch in bug 326337?
I would think so, yes.
If you want this fixed in the next three weeks you'll need to find a better owner.
Johnny or Boris, can you take this on?
Moving out to 184.108.40.206 since peterv is out of town.
Created attachment 335415 [details] [diff] [review] This should do the trick
Comment on attachment 335415 [details] [diff] [review] This should do the trick It is different question if we need Bug 421228 on 1.8.
Gah. Yes, we'd need that; good catch. But there is no nullprincipal on 1.8... I guess we could make it use about:blank?
Actually, I don't think we need it. The data document content policy won't get bypassed on branch, and that's all that really matters here, I think.
Comment on attachment 335415 [details] [diff] [review] This should do the trick Is it going to matter that in a redirect case the principal doesn't get updated? On branch they're guaranteed same-origin so they would at least be equivalent principals, but is this case handled OK for XS-XHR on trunk? regardless, for 1.8 branch approved for 220.127.116.11, a=dveditz for release-drivers
Fix checked into 1.8 branch.
We don't have XS-XHR on trunk yet, and when we do we'll likely still stamp the document with the loader principal so that the loader can actually get that data. Thanks for checking this in!
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/2008082909 Firefox/22.214.171.124.
Removing the blocker flag for a release _after_ the one this was fixed in, since it's not really relevant anymore.