New issue
Advanced search Search tips
Starred by 7 users

Issue metadata

Status: Duplicate
Merged: issue 769012
Closed: Dec 2017
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug

Blocked on:
issue 797712

Sign in to add a comment

Issue 763673: mime error when <script type="module" src="./example.js"> in webextension

Reported by, Sep 9 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3210.0 Safari/537.36

Steps to reproduce the problem:
1. add a script tag with type = "module" in html page of a webextension
2. mime error because the imported js file has no mime and ES6 modules only accept javascript mime

What is the expected behavior?
<script type="module" src="./example.js"> should import the expected javascript file in the page with the javascript mime

What went wrong?
the mime is null when trying to import a javascript file to the page via a script tag with type = "module"

Did this work before? No 

Chrome version: 63.0.3210.0  Channel: n/a
OS Version: 10.0
Flash Version:

Comment 1 Deleted

Comment 2 by, Sep 11 2017

Components: -Blink Platform>Extensions Blink>HTML>Script

Comment 3 by, Sep 13 2017

Labels: Needs-Feedback
@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.

Comment 4 by, Sep 23 2017
Simply add the extension to chrome and open the option page
21.7 KB View Download

Comment 5 by, Sep 23 2017

Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "" to the cc list and removing "Needs-Feedback" label.

For more details visit - Your friendly Sheriffbot

Comment 6 by, Sep 26 2017

Labels: -Type-Bug -Pri-2 hasbisect-per-revision ReleaseBlock-Stable M-61 Needs-Triage-M63 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Status: Assigned (was: Unconfirmed)
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:

From the above change log suspecting below change
Change-Id: I9533fdb325fcecccedbf24b9819e65f116a17c11

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.


Comment 7 by, Sep 26 2017

Labels: -Type-Bug-Regression Type-Bug
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),
(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?

Comment 8 by, Sep 26 2017

Labels: -ReleaseBlock-Stable
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.

Comment 9 by, Sep 26 2017

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
30.2 KB View Download

Comment 10 by, Nov 28 2017

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.

Comment 11 by, Dec 22 2017

I think this is the same issue:

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

For reference: matching Firefox bug:

Comment 12 by, Dec 22 2017

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.

Comment 13 by, Dec 22 2017

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

Comment 14 by, Dec 22 2017

Mergedinto: 769012
Status: Duplicate (was: Assigned)

Comment 15 by, Dec 27 2017

Blockedon: 797712

Sign in to add a comment