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

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Mossroy]

Attachment: 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.

Comment 1

[Robert Longson [:longsonr]]

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

Comment 2

[Thomas Wisniewski]

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?

Comment 3

[Masatoshi Kimura [:emk]]

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

Comment 4

[Mossroy]

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.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

We still need regression range here somehow.

Comment 6

[Masatoshi Kimura [:emk]]

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

Comment 7

[Thomas Wisniewski]

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.

Comment 8

[Masatoshi Kimura [:emk]]

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

Comment 9

[Thomas Wisniewski]

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.