bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Firefox 54 does not allow XMLHttpRequest to read local files from local HTML, when Firefox 53 did

RESOLVED FIXED in Firefox 55



9 months ago
9 months ago


(Reporter: Mossroy, Assigned: bobowen)


({regression, site-compat})

54 Branch
regression, site-compat
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox54 wontfix, firefox55 fixed)



(1 attachment)



9 months ago
Created attachment 8879292 [details]

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?
Flags: needinfo?(mossroy)

Comment 2

9 months ago
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.

Comment 4

9 months ago
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.
Flags: needinfo?(mossroy)
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.

Comment 7

9 months ago
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.
Last Resolved: 9 months ago
Depends on: 1321430
Resolution: --- → FIXED
Target Milestone: --- → mozilla55

Comment 9

9 months ago
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.
Keywords: site-compat
Assignee: nobody → bobowencode
Blocks: 1344957
Has Regression Range: --- → yes
status-firefox54: --- → wontfix
status-firefox55: --- → fixed
status-firefox-esr52: --- → unaffected
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.