If http pages that are allowed to use file:// URIs (via the capability.policy.* prefs) use them as sub-resources, these will fail to load when file read permissions are removed from web content process. The proposed solution is to run these whitelisted domains in the file content process.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8026bfe24c0171d50dc9edb2829f12df40c4cdf2 https://treeherder.mozilla.org/#/jobs?repo=try&revision=e7360535e778157fb8c65894ce0bd3c59622219a The Windows 10 jobs seem to be broken on a lot of recent try pushes.

This is required so that we can check the whitelist and run domains that are allowed to use file:// URIs in the file content process.

Comment on attachment 8886945 [details] [diff] [review] Part 2: Run file://URI whitelisted domains in a file content process Review of attachment 8886945 [details] [diff] [review]: ----------------------------------------------------------------- r=me but please make sure the question below gets answered either in the code comments, or on the bug, or by changing the patch. :-) ::: browser/modules/E10SUtils.jsm @@ +51,5 @@ > return WEB_REMOTE_TYPE; > } > > + // If the domain is whitelisted to allow it to use file:// URIs, then we have > + // to run it in a file content process, in case it uses file:// sub-resources. Shouldn't this check come before the !aPreferredRemoteType default-to-web-process?

(In reply to :Gijs from comment #5) ... > > + // If the domain is whitelisted to allow it to use file:// URIs, then we have > > + // to run it in a file content process, in case it uses file:// sub-resources. > > Shouldn't this check come before the !aPreferredRemoteType > default-to-web-process? You're right it should, the current code happens to work when navigating from a parent run page because the web remote type gets thrown out by a check in the child. Then as the preferred remote type is web for the next check in the parent we finally get to the correct file remote type. However, we obviously don't want to go through that rigmarole, changed locally, thanks. :-)

Comment on attachment 8886944 [details] [diff] [review] Part 1: Expose file:// URI whitelist check to chrome JS r=me

Pushed by bobowencode@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b4f4996c541e Part 1: Expose file:// URI whitelist check to chrome JS. r=bz https://hg.mozilla.org/integration/mozilla-inbound/rev/137cb6b5df67 Part 2: Run file://URI whitelisted domains in a file content process. r=Gijs https://hg.mozilla.org/integration/mozilla-inbound/rev/078a6b523cc1 Part 3: Make sure domains whitelisted for file:// URI use run in file contest process. r=Gijs

https://hg.mozilla.org/mozilla-central/rev/b4f4996c541e https://hg.mozilla.org/mozilla-central/rev/137cb6b5df67 https://hg.mozilla.org/mozilla-central/rev/078a6b523cc1