To simplify reproducibility, can you attach a page and script?

Attached an example. 

To get the specific error I am talking about on windows, you need to start chrome with --allow-file-access-from-files, and then try to load index.html as a file directly. 

Result is the MIME type checking error. No error results if index.html is loaded from a server and the script runs correctly.

I am unsure if this is a big deal on pc, but its an issue when trying to use apache cordova on android while using chrome webview, since that loads pages from file://.

Deleted: 824651.7z 408 bytes

824651.7z 408 bytes Download

(Copying some folks over from  issue 797712 )

I don't understand why this isn't already working correctly. Even if I manually add "HKCR\.js\Content Type" = "application/javascript", the same error occurs when the HTML file loads. 

https://cs.chromium.org/chromium/src/net/url_request/url_request_file_job.cc?l=213&rcl=2636fba313a00683509bc25cf4e79ad1f917ee49 looks like it should be picking up the .JS->application/javascript mapping.

Ah. I think the actual problem is here:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/modulescript/DocumentModuleScriptFetcher.cpp?l=50&rcl=2636fba313a00683509bc25cf4e79ad1f917ee49

  // We use ResourceResponse::HttpContentType() instead of MimeType(), as
  // MimeType() may be rewritten by mime sniffer.
  if (!MIMETypeRegistry::IsSupportedJavaScriptMIMEType(
          response.HttpContentType())) {

Thank you for reporting this issue.

So far, module scripts on file:// are intentionally not supported, at least for production use cases, because module scripts require CORS and correct Content-Type headers (with correct MIME type) for security, but file:// doesn't provide neither.

As for the Windows case, the use cases for file:// module scripts seem only for debugging purpose (because anyway we need --allow-file-access-from-files to bypass CORS).
We might be able to add a debug-only flag to bypass the MIME type check if this is highly needed.
(Although I feel it is not so helpful because testing locally with --allow-file-access-from-files will miss many problems that would happen in the production, including CORS errors)

As for the Apache Cordova case, does this occur in production deployment (not only in local debugging)?
If so, we should be more careful, and need more inputs (from the reporter and //net & modules people).

As commented in the source code, Blink intentionally checks Content-Type HTTP header, not ResourceResponse::MimeType(), due to a strong initiative for avoiding MIME type sniffing.
So if we want to support this case, we might want to add Content-Type header to file:// responses outside Blink, or add file://-specific code to Blink (not so sure though).

+kouhei@ +domenic@ as module script experts.

Does happen in Cordova production aswell.

I'm personally fine special casing file://.../hoge.js so they are treated as it had correct MIME type.
IIRC Firefox does that already.

> I'm personally fine special casing file://.../hoge.js so they are treated
> as it had correct MIME type.

I think I agree that treating `.js` files served from `file:` as JavaScript is a reasonable thing to do. That's what we do for `.css`, and doing it for other common types might allow us to be more agressive about enforcing MIME types in general, by removing the development environment case as a blocker.

That said, module scripts require CORS opt-in for the script content. I'm much more reticent to start creating automatic CORS opt-ins for `file:` content (e.g. automating the behavior hiroshige@ points to in the `--allow-file-access-from-files` flag), as that seems like it's a big step down the path to accidental data leakage.

The CORS error does not appear to me on Cordova. Whether it would still appear afterwards if the MIME thing was changed, or if Cordova (or its whitelist plugin) handles that, I don't know.

The CORS issue first came up for me, when trying to duplicate the error on Windows Chrome as requested in comment #1.

This still seems to be an issue.

Globals created in imported native modules via 'window.' are not accessible :- 

    Uncaught ReferenceError: AGlobal is not defined
        at test1.html:6

Deleted: test1.html 210 bytes

test1.html 210 bytes View Download

Deleted: test.mjs 77 bytes

test.mjs 77 bytes Download

@hiroshige: Any updates here? This happens with any Apache Cordova app that attempts to use ES6 modules, as stated in comment #8.