New issue
Advanced search Search tips
Starred by 7 users

Issue metadata

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

Blocked on:
issue 797712



Sign in to add a comment
link

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

Reported by banoushi...@gmail.com, 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 chrishtr@chromium.org, Sep 11 2017

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

Comment 3 by pnangunoori@chromium.org, Sep 13 2017

Cc: pnangunoori@chromium.org
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 banoushi...@gmail.com, Sep 23 2017

https://github.com/Banou26/ES6ModulesWebExt
Simply add the extension to chrome and open the option page
Result:
chrome_2017-09-23_18-58-28.png
21.7 KB View Download

Comment 5 by sheriffbot@chromium.org, Sep 23 2017

Project Member
Labels: -Needs-Feedback
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

Comment 6 by krajshree@chromium.org, 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
Owner: kouhei@chromium.org
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: 
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...!!

Comment 7 by hirosh...@chromium.org, Sep 26 2017

Cc: hirosh...@chromium.org
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),
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?

Comment 8 by pbomm...@chromium.org, 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 banoushi...@gmail.com, 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
Result:
chrome_2017-09-26_20-44-19.png
30.2 KB View Download

Comment 10 by sombrade...@gmail.com, 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 jakob.li...@gmail.com, Dec 22 2017

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

Comment 12 by elawrence@chromium.org, 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 jakob.li...@gmail.com, Dec 22 2017

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

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

Comment 14 by elawrence@chromium.org, Dec 22 2017

Mergedinto: 769012
Status: Duplicate (was: Assigned)

Comment 15 by hirosh...@chromium.org, Dec 27 2017

Blockedon: 797712

Sign in to add a comment