@banoushirosaki -- Thanks for reporting this issue. Could you please provide sample HTML files and extensions to replicate this issue. This would help us in further triaging the issue.

Thanks in advance. 

https://github.com/Banou26/ES6ModulesWebExt
Simply add the extension to chrome and open the option page
Result: 

Deleted: chrome_2017-09-23_18-58-28.png 21.7 KB

	chrome_2017-09-23_18-58-28.png 21.7 KB View Download

Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 using chrome stable version #61.0.3163.100 and latest canary #63.0.3223.8.

Bisect Information:
=====================
Good build: 61.0.3156.0	 Revision(486205)
Bad Build : 61.0.3158.0	 Revision(486952)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/c593f6ad3ceb7b54a7eebc22ee8d15ba6aeaf206..ecf1fe5f9d91a20ec6b6ac615e919174b78a4db2

From the above change log suspecting below change
Change-Id: I9533fdb325fcecccedbf24b9819e65f116a17c11
Reviewed-on: https://chromium-review.googlesource.com/566746

kouhei@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding label ReleaseBlock-Stable as it seems to be recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

This is because the chrome-extension:// files are served without Content-Type headers, and the spec of ES6 Module require valid MIME type (as the console error message says).

This is not a regression (ES6 Module is a new feature and the console error start appearing just because we added the console error code).

To support ES6 Modules in extensions, we have to either
(1) Make chrome-extension:// files served with Content-Type response headers (at least .js files),
OR
(2) Bypass MIME type check in ScriptLoader when it is served from extensions.

I feel (1) is cleaner in terms of loading.

Extension people, WDYT? Or is there any way to specify Content-Type for files served   by extensions?

Based on above comment I am assuming this isn't a stable blocker, hence removing blocker. Please do correct me if this still need to be a blocker.

I don't know if i should make another issue but after hirosh...@ asked the question "Or is there any way to specify Content-Type for files served   by extensions?"
I though of using service workers to modify the headers of the ES6 module file to the JS mime
But it looks like we can't load service workers either because of the same problem, wrong mime
I edited the repo with with the code to load the service worker
Result: 

Deleted: chrome_2017-09-26_20-44-19.png 30.2 KB

	chrome_2017-09-26_20-44-19.png 30.2 KB View Download

This actually blocks us from being able to move packaged apps to ES modules as well. I'd like to shift Caret over from AMD, since it would be much easier to handle shared code between background and UI scripts that way, but I can't currently do that.

I think this is the same issue: https://bugs.chromium.org/p/chromium/issues/detail?id=769012

It's status got changed to fixed, but one user reports it as still-reproducable.

For reference: matching Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1404727

Yes, this should be dupe of  Issue 769012  and thus now fixed in 63.0.3227.0 and later. If you can repro after that build, please supply a test case.

I can confirm this is fixed in 64.0.3282.24, tested with this code:

https://github.com/jaylinski/webextension-module-test