If you open a local HTML file (file:///path/to/index.html) on Firefox 54, and this web page tries to read another local file in the same path through XMLHttpRequest, it returns an HTTP 200, but with empty content. On Firefox <54, it was returning the file content. Is this expected behavior? I did not see anything related in the changelog. Steps to reproduce : - unzip the attached testcase, and open index.html in Firefox 53 - the console log shows that the XMLHttpRequest returned the file content - open the same file with Firefox 54 - the console log shows that the XMLHttpRequest returned no content Expected behavior : Firefox 54 should behave like Firefox 53, or this should be explained and mentioned in the changelog (with workarounds) There seems to be same kind of restriction on Chromium/Chrome, but it can be overridden with --allow-file-access-from-files command-line parameter. Is there any similar workaround on Firefox? What is surprising is that https://bugzilla.mozilla.org/show_bug.cgi?id=1371596 (which asks to block this kind of access) has been closed as invalid 10 days ago.

Do you fancy using http://mozilla.github.io/mozregression/ to tell us exactly what patch regressed this behaviour?

This is indeed not working in the actual 54 release on my linux64 box, but it seems to be working during mozregression (--bad=54), as well as today's nightly. Might it be something specific to the release configuration?

The test case is working in 54 with e10s disabled, but fails with e10s enabled.

I confirm that disabling e10s (on Firefox 54) is a working workaround for this issue. My Firefox profile has some addons marked as incompatible with e10s : if I set browser.tabs.remote.force-enable to true (which forces e10s), the issue is there (no content returned by XHR); if I don't set it to true, e10s is disabled and XHR returns the file content. I suppose it's no use running mozregression any more, as Thomas Wisniewski already did.

We still need regression range here somehow.

mozregression can set pref values (such as browser.tabs.remote.force-enable=true) while bisecting.

I may have found a lead: browser.tabs.remote.separateFileUriProcess. It's set to true on nightly builds, and when I set it to false the test case fails (returns null). It's not present by default in 54, but when I create it and set it to true, the test case starts working even in e10s mode.

Oh, then this will be fixed in Release builds since Firefox 55.

Yes. For the record, mozregression claims it was bug 1344957 which caused things to stop working when browser.tabs.remote.force-enable=false. And since those affected in 54 can probably just create browser.tabs.remote.force-enable=true, I'm guessing there isn't much left for us to do here.