https://chromium-review.googlesource.com/c/chromium/src/+/1117070 adds the entry to ResourceType.js, but AFAICT that only affects DevTools, and not Chrome Extensions.

https://chromium-review.googlesource.com/c/chromium/src/+/1117178 adds the entry to WebUIDataSourceImpl::GetMimeType, which we should do anyway. However, based on the error message in your screenshot, it seems like this is unrelated to mjs not working in extensions.

Devlin, could you take a look please?

Dang, again?

Revision aed0e5425bf2021fac85173daac10145f6a58a2a fixed this for JS files in general - we needed to bump up JS to be in the primary mime type mapping in mime_util.cc.

+asanka@ - do you have preferences of the best approach here?  It seems a bit odd to add .mjs to primary mappings (I don't even see it in secondary mappings).  On the other hand, I'm not really keen on adding a separate "mime type mapping" concept to extensions code.

@rdevlin.cronin: Setting

{"application/javascript", "js,mjs"}

should work. However, I've been unable to find a clear ref about what the expected mimetype for mjs should be - do you have a canonical reference?

@rsleevi https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ and https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages , the recommendation is `text/javascript`

However, any JS MIME should work.

> Setting {"application/javascript", "js,mjs"} should work.

Right - this is what I was referencing when I mentioned adding .mjs to kPrimaryMappings.  I just wasn't sure if mjs was canonical enough (even with the draft specs) to add to primary mappings when other established types (e.g., json, mp3, zip, png) are still in secondary mappings.  Though, I don't really know what the criteria for something being in primary vs secondary mappings are. :)

The MIME type should ideally be text/javascript and not application/javascript indeed. This matches the HTML Standard's as well as our own external recommendation: https://developers.google.com/web/fundamentals/primers/modules#mjs

@Comment 9:

Got it, thanks for clarifying. kPrimary vs kSecondary is not about popularity, but affects the application logic for prioritization:
- GetPreferredExtensionForMimeType, we return (OS, primary, secondary).
- GetMimeTypeFromExtension, we return (primary, OS, secondary)
- GetWellKnownMimeTypeFromExtension, we return (primary, secondary)

So whether or not it's in secondary affects whether or not the OS can override it.

@Comment 10: Got a link to the standard cite? I'd love to check cross-browser at how Safari and Firefox are mapping that :)

https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages

“Servers should use text/javascript for JavaScript resources. Servers should not use other JavaScript MIME types for JavaScript resources, and must not use non-JavaScript MIME types.”

Ah, missed the cite in Comment #8.

I don't think there should be an issue with changing to "text/javascript" and adding "mjs" as an extension.

The original logic mapped "js" to "application/x-javascript" (from the initial commit). 

https://chromium.googlesource.com/chromium/src/+/2eb968f31ede2bd1825961fba841277d71f5898d%5E%21/ changed that to be "application/js".

It's been untouched since then.

Adding "mjs" to primary mapping and changing the JavaScript MIME type to "text/javascript" is ok by me.

My rule-of-thumb is to consider kPrimaryMappings to be the set of mappings that's necessary to be consistent across OS/platforms in order for the webplatform to work. kSecondaryMappings, as Ryan pointed out, is the set of mappings that make sense for platforms to override if they so choose.

Since this has come up a few times I'll also add some guidelines to the file for future reference.

Cool!  Then if there are no objections, I'll start in on this.  Thanks, folks!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91e57aa25b18a34e78933e76cf0c214ea1f14d73

commit 91e57aa25b18a34e78933e76cf0c214ea1f14d73
Author: Mathias Bynens <mathias@chromium.org>
Date: Fri Jun 29 02:11:09 2018

Add mjs to Common.ResourceType._resourceTypeByExtension

Our recommendation is to use `mjs` to denote JavaScript modules as
opposed to classic scripts:
https://developers.google.com/web/fundamentals/primers/modules

Bug:  chromium:857076 
Change-Id: I6d3f77c62bd9a14bec484dfe897aff754301bff7
Reviewed-on: https://chromium-review.googlesource.com/1117070
Reviewed-by: Paul Irish <paulirish@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Paul Irish <paulirish@chromium.org>
Cr-Commit-Position: refs/heads/master@{#571361}
[modify] https://crrev.com/91e57aa25b18a34e78933e76cf0c214ea1f14d73/third_party/blink/renderer/devtools/front_end/common/ResourceType.js

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5074301504ea31a87c0bd9caddec42c2ff0841bd

commit 5074301504ea31a87c0bd9caddec42c2ff0841bd
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Mon Jul 02 16:41:51 2018

[Extensions + Net] Add .mjs to MIME type mappings

Add .mjs to type mappings for the javascript MIME type. This is
necessary for .mjs to be recognized as a valid for use in modules
when served by the extension protocols, where the mime type is
determined by our net code (as opposed to a server).

Update the extension API test for modules to include a .mjs file test.

Bug:  857076 
Change-Id: Ib14cabbc52057cfb57c933de5a9c3ed4b13b87d2
Reviewed-on: https://chromium-review.googlesource.com/1117203
Reviewed-by: Asanka Herath <asanka@chromium.org>
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#571921}
[modify] https://crrev.com/5074301504ea31a87c0bd9caddec42c2ff0841bd/chrome/test/data/extensions/api_test/modules/background.js
[modify] https://crrev.com/5074301504ea31a87c0bd9caddec42c2ff0841bd/chrome/test/data/extensions/api_test/modules/module.js
[add] https://crrev.com/5074301504ea31a87c0bd9caddec42c2ff0841bd/chrome/test/data/extensions/api_test/modules/module.mjs
[modify] https://crrev.com/5074301504ea31a87c0bd9caddec42c2ff0841bd/net/base/mime_util.cc

This should be fixed for extensions beginning in 69.0.3480.0.  Let me know if you still have any issues, and thank you for filing the bug!