Created attachment 8879292 [details] testcase-xhr-local-file.zip 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.
Keywords: regression, regressionwindow-wanted
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.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Depends on: 1321430
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
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.
Assignee: nobody → bobowencode
Has Regression Range: --- → yes
status-firefox54: --- → wontfix
status-firefox55: --- → fixed
status-firefox-esr52: --- → unaffected
You need to log in before you can comment on or make changes to this bug.