It looks like a bug at Chrome's side instead of V8. I don't think "experimental web platform features" flag can enable ES Module in Chrome extension until ES Module is on by default.

Moved issue v8:6442 to now be  issue chromium:728377 .

options pages of extensions are also missing module script support

adding this line to the example manifest.json should add an options page:

  "options_page": "index.html",

in the slightly longer term i'd like to see module script support in content scripts and chrome.tabs.executeScript, but it would probably require changes to some extension apis

Extension background pages should have all the same capabilities as normal web features, so *if the flag is enabled* (can you confirm it is?), I would have expected this to work in extensions.

jbroman@, do you know who owns modules in chrome?

it's adamk :)

+kouhei and hiroshige, who've been driving this on the Blink side. Any reason why <script> would behave differently in a background page?

Yes. Our implementation is currently bound to "main world".

I think background pages (as opposed to content scripts) do run in the main world (similarly, they do have access HTML elements, which are also restricted to the main world).

To echo Devlin's question, have you enabled modules in general? (This is only a bug if they work in non-extension pages but not in extension pages.)

i attached some screenshots (from a fresh install of chrome canary with "experimental web platform features" to enable modules)

i'm using the sample extension provided by the issue submitter, also attached as a zip file for convenience

"web page.png": index.html is loaded from a simple http server -> the module script works correctly and logs the number to the console

"background page.png": index.html is the background page of the extension -> module script didn't run, nothing is logged

"options page.png": index.html is the options page of the extension -> module script didn't run, nothing is logged

i hope this is helpful, i'm looking forward to the day i can write extensions using module scripts

Deleted: extension.zip 701 bytes

extension.zip 701 bytes Download

Deleted: web page.png 7.7 KB

	web page.png 7.7 KB View Download

Deleted: background page.png 30.4 KB

	background page.png 30.4 KB View Download

Deleted: options page.png 8.2 KB

	options page.png 8.2 KB View Download

Still an issue in Chrome 62.  Related to https://bugs.chromium.org/p/chromium/issues/detail?id=738739 ?  There seems to be a need to examine the intersection between Chrome extensions and JS modules--modules will work great for served browser applications, but we extension authors would love to use them, yet are hobbled by implementation side-effects we can't workaround without separate tooling like we had to use before (e.g. weblack + transpiling).

FYI: This may be fixed by  issue 769012  (patch landing in Canary in the next day or two).

assigning a tentative priority.

Has anyone tried this on 63.0.3227.0 or higher?

@rdevlin It appears to work on Chrome Canary 64.0.3244.0

Can't you tell by running the test?

Yeah, I've tested the simple cases (like the one mentioned in the original report).  I was curious if anyone had tried something more complex, and if they ran into any issues, before closing this out.  Glad to hear it's working for you.

I also only used the test you posted, nothing more complex.

Errors: Failed to load module script: The server responded with a non-JavaScript MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec.

 issue 769012  has not fix.

@21: Which Chrome version/OS are you on, and can you include the test extension?  (The one posted in the original report works fine for me on Canary)

@22:
Test in home pc: pass
Test in company pc: fail to pass
😥

I snip a screenshot.(also test on version 64.0.3246.2 in my company pc)

Deleted: QQ截图20171023102147.png 178 KB

	QQ截图20171023102147.png 178 KB View Download

@23 Interesting.  If I had to guess, I'd say this is another instance of  issue 762483 , where we found that something else on the machine had changed the mime type associated with JS files.

+a few folks from that bug - falken@, mmenke@, davidben@: this seems to be another time when a registry key might be able to cause hard-to-diagnose problems associated with mime types.  Do we really want other programs to be able to set JS's mime type in Chrome to be text/plain?

[+asanka, +rsleevi], who may also have opinions here.

#24: There's a concept of a set of "primary mappings" that are compiled in and are intended to be non-overridable by the underlying platform. I'd consider adding '.js' to the list there. (Ref: https://cs.chromium.org/chromium/src/net/base/mime_util.cc?rcl=9a494a4e49188d2870df05b3e94c665743d984ff&l=78)

@26 I suggested this too in https://bugs.chromium.org/p/chromium/issues/detail?id=762483#c7, so I'm very supportive :)

rsleevi@ or mmenke@, any objections?

Is there a reason js wasn't in the list to begin with?  If not, seems like quite an oversight.  Is so, I'd like to understand that reason.

I haven't had a chance to trace through all the code (got a flight to catch), but the only potential concern would be making sure that the code path is not involved in mime-sniffing. If the function is shared with the mime-sniffing code, then it would be potentially dangerous (changing how JS is sniffed).

Adding mkwst for visibility, but like I said - I haven't dug in to know if this is one of the shared functions.

It looks to me like this would on affect extension -> mime type mappings, which aren't used in the normal mime sniffing path.

They are used in at least on place for downloads, and other random locations, so changing behavior here may have some impact on web stuff, just not on MimeSniffingResourceHandler.

This has been fixed.  Merging.