Cannot use import in unpacked extension despite Experimental Web Platform flag enabled
Reported by
che.fis...@gmail.com,
Jul 2 2017
|
|||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3147.0 Safari/537.36
Steps to reproduce the problem:
0. Create a basic extension which does something using chrome.runtime.onStartup.addListener(function callback). Example code below:
//main.js
'use strict'
import { helpers } from './globals.js'
const addContextMenus = () => {
helpers.getDirectoryContents('commands', (contents) => {
for (const entry of contents) {
const properties = {
id: entry,
title: entry,
contexts: ['all']
}
chrome.contextMenus.create(properties)
console.log(`Created context menu ${properties.title}`)
}
})
}
chrome.runtime.onStartup.addListener(addContextMenus())
1. Create a simple globals/helpers file which exports some functions (see attached file)
2. Use ES6 import and export syntax to import and export the functions
3. On loading the unpacked extension, "Uncaught SyntaxError: Unexpected token import" is thrown
What is the expected behavior?
Import and export should be supported in Chrome Canary so long as the Experimental Web Platform flag is enabled
What went wrong?
"Uncaught SyntaxError: Unexpected token import" is thrown during loading of extension
Did this work before? No
Chrome version: 61.0.3147.0 Channel: canary
OS Version: OS X 10.12.5
Flash Version:
,
Jul 2 2017
FWIW, not related to the issue but addContextMenus() above doesn't return anything so chrome.runtime.onStartup.addListener won't add a listener.
,
Jul 3 2017
,
Jul 5 2017
Current implementation follows the HTML spec strictly, and checks MIME type for the loaded JS modules, but I guess for extensions the file will be loaded via filesystem (or zip file?), so no MIME type is provided internally - that's why ES6 modules don't work for extensions. Maybe Blink implementation can loose the check for files coming from extensions.
,
Jul 5 2017
As this issue related to ES6 import and export js files,could someone from dev team please look into this issue. Adding 'TE-NeedsTriageHelp' label for further investigation from dev. Thank you..!!
,
Jul 5 2017
,
Jul 5 2017
Please ignore comment#6. Che.fisher@,Could you please provide us sample extension for ease of reproducing the issue from TE end. Thanks in advance.
,
Jul 5 2017
related bug ("background page of extension does not implement ES-Next module"):
https://bugs.chromium.org/p/chromium/issues/detail?id=728377
that one uses an html background page though, while this one might be specifying the .js file in manifest.json directly which only does non-module scripts (explains the syntax error)
in the other bug the script doesn't run at all, probably caused by the mime type checking mentioned in comment 5
,
Jul 18 2017
jmukthavaram@chromium.org Here is a sample extension which demonstrates the issue: https://github.com/gyorgy-farkas/crbug-738739 JS files are not loaded when imported by a <script type="module"> tag in HTML, fails with this error: index.js:1 Failed to load module script: The server responded with a non-JavaScript MIME type of "". Strict MIME type checking is enforced for module scripts per HTML spec.
,
Jul 18 2017
c#10 indicates that kochi@'s hypothesis on c#5 was correct. Looks like the extension protocol handler never sets MIME type. https://cs.chromium.org/chromium/src/extensions/browser/extension_protocols.cc?type=cs&q=URLRequestExtensionJob&sq=package:chromium&l=168 lazyboy: Would it be possible to serve application/javascript MIME-type if the resource ends w/ js suffix? The HTML spec requires module scripts to have correct Javascript MIME type, but IIUC user can't specify the MIME types of the resource in extensions.
,
Jul 18 2017
After re-reading the original report, I believe the issue could have been that they forgot to add type="module" to the script tag. Without type="module" the browser throws a syntax error, as expected. However, when adding the tag correctly, Chrome never even gets to parsing the JS file, and throws the error as explained in #10. Thus I think the MIME type check problem is different from the original report, would it make more sense to open a new issue?
,
Aug 17 2017
I also encountered this issue on a Mac in Chrome 61. The issue occurs with even the simplest of use cases, even without a startup listener.
In an extension html page I specify the following in the page's head element:
<script src="test.js" type="module"></script>
test.js is located within the extension. The test.js does nothing more than `console.log('hello');`. Upon visiting the page the following message appears in the console:
Failed to load module script: The server responded with a non-JavaScript MIME type of "". Strict MIME type checking is enforced for module scripts per HTML spec.
If I change the html to type="application/javascript", and use an import statement in test.js, then there is no longer a module loading issue, instead there is the expected syntax error.
,
Sep 24 2017
It is unfortunate that even though Chrome 62 supports JS modules, I can't easily use them in extension development. In the meantime, I still have to use something like webpack in order to "fix" import and export--in which case, there is zero point in having native module support in the browser. Is this actively being worked on? I'd love to simplify my extension-building toolchain.
,
Sep 28 2017
This may be fixed with issue 769012 (patch landing in Canary in the next day or two).
,
Aug 1
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by che.fis...@gmail.com
, Jul 2 2017