New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 15 users

Issue metadata

Status: Duplicate
Merged: issue 769012
Closed: Jun 2018
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: FeatureRequest

Blocked on:
issue 797712

Previous locations:

Sign in to add a comment

Issue 728377: background page of extension does not implement ES-Next module

Reported by, May 27 2017

Issue description

Version: 60.0.3112.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
OS: Windows 10.0.15063
Architecture: x64

What steps will reproduce the problem?
1. create minimum chrome extension 

# manifest.json
  "manifest_version": 2,
  "name": "Tester",
  "version": "1.0.0",
  "background": {
      "page": "index.html"
  "permissions": ["<all_urls>"]

# index.html
<!DOCTYPE html>
<html lang="en">
    <meta charset="UTF-8">
    <script type="module" src="index.js"></script>

# index.js;

2. inspect background page.

What is the expected output?
output: 99

What do you see instead?
nothing output in console

Comment 1 by, May 27 2017

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.

Comment 2 by, May 31 2017

Labels: -Type-Bug Type-FeatureRequest

Comment 3 by, May 31 2017

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

Comment 4 by, May 31 2017

Components: Platform>Extensions

Comment 5 by, May 31 2017

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

Comment 6 by, Jun 2 2017

Components: Blink
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?

Comment 7 by, Jun 2 2017

Components: -Blink Blink>Bindings

Comment 8 by, Jun 2 2017

Components: -Blink>Bindings Blink>JavaScript>Language
it's adamk :)

Comment 9 by, Jun 2 2017

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

Comment 10 by, Jun 4 2017

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

Comment 11 by, Jun 5 2017

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.)

Comment 12 by, Jun 5 2017

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
701 bytes Download
web page.png
7.7 KB View Download
background page.png
30.4 KB View Download
options page.png
8.2 KB View Download

Comment 13 by, Jun 12 2017

Status: Assigned (was: Untriaged)

Comment 14 by, Sep 24 2017

Still an issue in Chrome 62.  Related to ?  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).

Comment 15 by, Sep 28 2017

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

Comment 16 by, Oct 19 2017

Labels: Pri-2
assigning a tentative priority.

Comment 17 by, Oct 19 2017

Has anyone tried this on 63.0.3227.0 or higher?

Comment 18 by, Oct 19 2017

@rdevlin It appears to work on Chrome Canary 64.0.3244.0

Can't you tell by running the test?

Comment 19 by, Oct 19 2017

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.

Comment 20 by, Oct 19 2017

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

Comment 21 by, Oct 20 2017

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.

Comment 22 by, Oct 20 2017

@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)

Comment 23 by, Oct 23 2017

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)
178 KB View Download

Comment 24 by, Oct 23 2017

@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?

Comment 25 by, Oct 23 2017

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

Comment 26 by, Oct 23 2017

#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:

Comment 27 by, Oct 23 2017

@26 I suggested this too in, so I'm very supportive :)

rsleevi@ or mmenke@, any objections?

Comment 28 by, Oct 23 2017

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.

Comment 29 by, Oct 23 2017

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.

Comment 30 by, Oct 23 2017

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.

Comment 31 by, Dec 27 2017

Blockedon: 797712

Comment 32 by, Jun 27 2018

Mergedinto: 769012
Status: Duplicate (was: Assigned)
This has been fixed.  Merging.

Sign in to add a comment