1212722 - ES6 features (e.g. "let") don't work in background scripts

Status: RESOLVED DUPLICATE of bug 932513

(WebExtensions :: Untriaged, defect)

Description

[Giorgio Maone [:ma1]]

Steps to reproduce:

1. Install the attached XPI
2. Watch for the console

Expected result: "main.js says hello" in the console
Actual result: Syntax error in main.js, due to a let assignment and/or a template string usage (not sure which, it doesn't matter).

This is for scripts loaded through the "background": { "scripts": ["main.js"] } manifest.json syntax.

Scripts loaded by an actual background HTML page ( "background": { "page": "main.html" }) must be forced to use ES6 by using

<script type="application/javascript;version=1.7" src="main.js"></script>

rather than

<script type="text/javascript"></script>

or just

<script></script>

This causes a source-level incompatibility with Chromium, where both the "scripts" and the "page" directives are ES6-compatible "out of the box" (you just need to put "use strict" at the beginning of your script sources), while type="application/javascript;version=1.7" causes the script not to load at all.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Note that you probably don't want to do any magic transforms of the script tag to force v1.7, instead you might want to bundle babel with the runtime or something like that.  While things have hopefully improved on the trunk in the 5 months since I last asked (it looks like the problem is our chrome usages holding us back that need to be fixed now?), I was explicitly told that our let implementation is broken and not ES6 compliant in many cases.  See https://groups.google.com/forum/#!topic/mozilla.dev.platform/UGYxEgzEkZo for more discussion.  I'd suggest pinging the JS team for hopefully good news, but failing that, it seems like you don't want to depend on SpiderMonkey's implementation of "let" until it works without having to specify a version.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Bug 1202902 was the last major blocker I know of to an ES6-compliant let. There might be some more pieces, but I think we're pretty close. However, I think we should wait until all that stabilizes before we expose let to WebExtensions by default.

Comment 3

[Kris Maglione [:kmag]]

Based on comment 1, I'm inclined to wontfix this. The differing behavior in for loops will probably break some code written for Chrome (I know I've tried to write code that depended on that behavior, but didn't work with our implementation).

Most other ES6 features already work in background scripts, so we're probably much better off waiting for this to be turned on globally, rather than having extension scripts behave differently from ordinary web scripts.

Comment 4

[Giorgio Maone [:ma1]]

So, what's the story we need to tell to early adopters, especially those who have Chrome extensions using ES6 features, or of course those who are trying to port their existing Firefox add-ons, which surely contain a lot of this stuff?

Comment 5

[Kris Maglione [:kmag]]

I'm mostly worried that if we turn on support for `let`, but with incompatible semantics, things are going to break in unexpected ways, rather than in obvious ways, up front.

There's also the added problem that we don't have a way (that I know of) to turn on support for `let` without also turning on support for our other non-conformant JS 1.7/1.8 extensions.

Maybe we should add a flag to the "gecko" block of manifest.json for early adopters, who have read the caveats, to either enable our flavor of `let` in extension scopes, or pre-process scripts with Babel.

Comment 6

[Gabor Krizsanits (INACTIVE)]

(In reply to Giorgio Maone from comment #4)
> So, what's the story we need to tell to early adopters, especially those who
> have Chrome extensions using ES6 features, or of course those who are trying
> to port their existing Firefox add-ons, which surely contain a lot of this
> stuff?

For what it's worth we're allowing 'let' for jetpack add-ons ages ago. In fact the default version is 1.8 I think. Shouldn't be too hard to do it for tradition xul add-on either. So it's going to be very hard to sell why people cannot use ES6 features in the new and shiny API IMO. How about waiting with turning it on by default, but add a manifest flag for it for those who really wants to use it and add a warning in the docs that refers to the bug Bill mentioned?

Comment 7

[Kris Maglione [:kmag]]

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #6)
> For what it's worth we're allowing 'let' for jetpack add-ons ages ago. In
> fact the default version is 1.8 I think. Shouldn't be too hard to do it for
> tradition xul add-on either. So it's going to be very hard to sell why
> people cannot use ES6 features in the new and shiny API IMO.

It's not about allowing ES6 features. Most ES6 features already work in extension and web scripts. It's about non-standard extensions. If we set JS version to 1.8, we not only wind up with versions of `let` and `const` that don't conform to the standards (sometimes in subtle but important ways), but also a lot of other things, like our non-standard generator function syntax and protocol.

Comment 8

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Yeah, I'm pretty against exposing let until we actually make it compliant. We're facing a ton of add-on bustage because so many people rely on our broken behavior. The last thing I want to do is make more of that. I wish we could even stop people from using the ;version=1.7 thing, but that's probably hard.

Comment 9

[Kris Maglione [:kmag]]

Added a note to https://developer.mozilla.org/en-US/docs/preview-wiki-content#Miscellaneous_incompatibilities

Since we seem mostly agreed that this should only be turned on when it's compliant, duping to that bug.

Comment 10

[Kris Maglione [:kmag]]

Er, added a not to https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities#Miscellaneous_incompatibilities rather