A network error occurred thrown when using XMLHttpRequest on file protocol with Firefox 68

Add-ons Development
#1

Hi all,

The above code was working fine in Firefox 66 (content_script.js):

try {
  var status = -1
  var data = ''
  var path = 'file:///path/to/file.txt'
  var xhr = new XMLHttpRequest()
  xhr.open('GET', path, false)
  xhr.addEventListener('load', function () {
    status = this.status
    // status is 0 for local file mode (i.e., file://)
    if (status == 0 || status == 200) {
      data = this.responseText
    }
  });
  xhr.overrideMimeType('text/plain')
  xhr.send()
  console.log(data)
} catch (e) {
  console.log('error', e)
}

But with Firefox 68, I get “A network error occurred”.
Please note that it’s working fine when using http(s) protocol (for instance, var path = 'http://localhost/file.txt').

In the Firefox 68 release note, there’s two changes on XMLHttpRequest but, as far as I understand, they are related to my use case:

XMLHttpRequesthas been updated to no longer accept the non-standard moz-chunked-arraybuffer value for `responseType. Code still using it should be updated to use the Fetch API as a stream.

XMLHttpRequest now outputs a warning to console if you perform a synchronous request while handling an unload,beforeunload, or pagehide event.

Should I submit a bug on https://bugzilla.mozilla.org ? Is it intended?

#2
1 Like
#3

Thanks I missed that.
Do you know if they plan to restore this feature once they found a way to safely allows it?
I’m not sure how Chrome/Chromium handles this case but XHR on “file://” protocol is still allowed.

#4

Individual end users can roll back this change, but it’s difficult to recommend:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.

(2) In the search box above the list, type or paste uniq and pause while the list is filtered

(3) Double-click the privacy.file_unique_origin preference to switch the value from true (secure) to false (insecure)

As a risk mitigation, always download untrusted HTML to a separate folder from your other HTML files to minimize the risk of code in the file exfiltrating sensitive data.

1 Like
#5

If this is a CORS issue, couldn’t you just get a host permission for file URIs?

#6

Thanks!
For reference, it’s also working when security.fileuri.strict_origin_policy is disabled (false).

#7

Indeed, that would great. Maybe a special permission in the manifest: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions ?

#8

Oh, but please don’t do that. That is the preference which prevents “upward” navigation by saved pages to the rest of your system.

#9

Well, host permissions already support file URIs.