I have a patch in bug 353455 that would let us run mochitests from file:// URLs in the current Mochitest harness, except it doesn't work, because the harness is run from http://localhost:8888/, and it's not allowed to link to file:// URLs. The harness has an iframe, and it does "iframe.src = url;". With my patch, "url" could be a file:// URL. Even with an explicit enablePrivilege("UniversalXPConnect"), this doesn't work. Is there some way we could make this work, or is this a terrible idea in general?

So we could replace the system principal check in CheckLoadURIWithPrincipal with a UniversalXPConnect check in CheckLoadURI. It would give weirdness where <iframe src="x:"> and iframe.src="x:" behave differently (the former has no way to have UniversalXPConnect), but that might be ok.

(In reply to comment #0) > I have a patch in bug 353455 I'm pretty sure you meant bug 424484 here.

Yeah, thanks. That was the *attachment* number. (They're confusingly similar at this point.)

Does "UniversalFileRead" work? http://hg.mozilla.org/mozilla-central/annotate/118a9a77fa61/caps/src/nsScriptSecurityManager.cpp#l1276

UniversalFileRead seems like the right privilege...

We're attempting to get rid of UniversalXPConnect, UniversalFileRead and all its ilk. In fact, mochitests are the biggest blocker of doing so right now. So lets not build something new, especially for mochitests, that relies on it. One solution could be to allow "domains" to be configured by setting prefs. For example allow multiple prefs like pref("caps.domains.my_foo_domain", "file://a/b/c") pref("caps.domains.my_other_domain", "file://a/b/d") This would likely also help developers more than the current set of prefs. It will get tricky to do cross-domain tests though. But that doesn't seem to be solved in the current proposal either. It'd be fairly easy to do on platforms that allow symbolic links. Just create one directory with all the files, and multiple symbolic links to that directory.

Oh, I should also say, with the two example prefs above, we would consider file://a/b/c/subdir/index.html as same-domain with file://a/b/c/siblingdir/index.html but cross-origin with file://a/index.html and file://a/b/d/index.html

I think this is probably WONTFIX. We should just fix the chrome harness to actually be chrome, and then we could do this pretty easily.