1747665 - File:// URLs give "CORS request not http" error for modules, even with privacy.file_unique_origin false

Status: RESOLVED DUPLICATE of bug 1744965

(Core :: DOM: Security, defect)

Description

[hillexed]

Attachment: simple_test_case.zip

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

I want to use ES6 modules for my code to simplify spaghetti code and split my code across multiple files, and test my websites locally before deploying.

I made a .html file with "<script type="module" src="./alert_hi.js"> </script>", and opened that saved HTML file with firefox. Instead of running my module, I got a weird CORS error.

I've attached a small test case here. Download both normalscript.html and modules.html with alert_hi.js in the same folder, then try to open the files in firefox.

Actual results:

Normalscript.html runs the script, and alerts "hi!".

Opening modules.html, it does not run any script and does not alert "hi". I see an error in the console which says "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///tmp/test/alert_hi.js. (Reason: CORS request not http)".

I tried this with the privacy.file_unique_origin setting in about:config both turned on and turned off, and the same error appears each time, and the script doesn't run :(

Expected results:

Opening both normalscript.html and modules.html should have both run the script and alerted "hi".

As far as I can tell, according to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp and Bug 1558299 , the privacy.file_unique_origin setting in about:config is used to disable local cross-origin checking. If so, setting this to false should still allow me to acknowledge the risk and still use modules when testing locally.

This is a bit annoying. I shouldn't have to download and run an entire web server just to test a file locally.

Thanks!

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 4

[hillexed]

I don't think this is a duplicate. The MDN page I linked to mentions a different about:config setting from bug 1744965. As you can see from the bug 1744965, people expect opening HTML files locally to work, and will try it and get confused. If they do what the MDN page suggests and change privacy.file_unique_origin setting, it doesn't do anything, and the problem is still there.

Comment 5

[Robert Longson [:longsonr]]

You can always propose an update to MDN. The fact that MDN is wrong doesn't change this bug's underlying duplicate status

Comment 6

[hillexed]

Could you explain why it's a duplicate? As an user, part of the problem is how little info there is about why this happens and the rationale behind it, so it would be great to know more.

Or, would you prefer I ask on the linked duplicate bug?

Comment 7

[Gingerbread Man]

This happens because the preference privacy.file_unique_origin no longer exists.
Since the root cause is the same, this is a duplicate.
The MDN article is outdated; issue 11426 on GitHub has been filed for this.
See bug 1744965, comment 9 for a current workaround.

Comment 8

[hillexed]

Thanks! Hope that pull request gets merged soon. Maybe that page could also mention the "run a server" strategy in addition to the about:config page?

In my mind there's two parts to this bug. One part is that the workaround on MDN doesn't work (that's the duplicate). The second part is that scripts and module-loaded scripts should behave the same. That part isn't a duplicate.

It doesn't make sense to me that locally, <script src="./my_file.js"></script> works fine but <script type="module" src="./my_file.js"></script> doesn't. They should either both work or both not work.

I can see why based on Bug 1558299 firefox shouldn't allow XMLHttpRequest to work locally. But loading a module is different from an XMLHTTPRequest: images and PDFs aren't modules, and would fail to be parsed as modules, meaning that bug's technique doesn't apply. Therefore, there's no new risk. The bug, in my mind, is that file://s should be able to load modules, just like how they can load scripts today.