1213632 - Prevent WebExtensions attempts to use versioned script tags

Status: RESOLVED FIXED

(WebExtensions :: Untriaged, defect)

Description

[Kris Maglione [:kmag]]

+++ This bug was initially created as a clone of Bug #1212722 +++

A lot of developers are probably going to run into ES6 compatibility issues when attempting to port their Chrome extensions to Firefox. There's not much we can do about most of the problems until we have better compliance in Spidermonkey. In the mean time, we should try to direct developers to better solutions when they try to use missing features.

I'm proposing adding console messages, suggesting that developers use the Babel transcompiler (https://babeljs.io/) when:

* They attempt to use a <script> tag with ";version=*" in the type attribute, or,
* The JS engine emits a syntax error for a currently missing ES 6 feature.

It might even be worth adding a temporary manifest flag to silently do the transpilation, for the short/medium term, since it would be pretty trivial for us to do, and might significantly simplify some developers' lives.

Comment 1

[Jan de Mooij [:jandem]]

Keep in mind that we've had most ES6 features long before Chrome had them. Main exceptions still are let/const (due to tons of code depending on our old, non-standard semantics) and classes, both of those are close to being done, so hopefully this situation will be temporary.

Comment 2

[Kris Maglione [:kmag]]

That's true, and we support a lot of ES6 features that they don't, but this one has been particularly long in coming, and seems likely to bite a lot of developers before we get it fixed.

I'd like to show warnings for people attempting to use versioned JS scripts, in any case. Or to just ban them in web extensions entirely. Adding a message about `let` at the same time should be pretty trivial.

Comment 3

[Kris Maglione [:kmag]]

I did a quick test, and it looks like we'll be able to do this fairly easily with a content policy.

Comment 4

[Giorgio Maone [:ma1]]

Please give a big fat warning with links to relevant documentation but do not hard block them: I've got already code in production which uses this trick, and unfortunately I had shared it with developers who are using ES6 stuff in their Chrome extension and are trying to be early adopters, such as Whisper Systems.

Comment 5

[Kris Maglione [:kmag]]

Hm. That's exactly what I was trying to avoid by hard blocking as soon as possible...

Can you contact the people you've suggested this to and ask that they use Babel, or something similar, instead?

We could put this behind a preference, or start with warnings before moving to hard blocks. But if we start doing things like that for features that haven't even made it to release yet, I think we're going to wind up in a very bad place.

Comment 6

[Giorgio Maone [:ma1]]

(In reply to Kris Maglione [:kmag] from comment #5)
> Hm. That's exactly what I was trying to avoid by hard blocking as soon as
> possible...

I understand that, and I tend to agree. 
But we must be very good at communicating the mitigation options (like Babel) and how to use them optimally, because add-ons developers take the most advanced features provided by their scripting engine for granted, even if they're experimental and not exposed to unprivileged web pages.

> Can you contact the people you've suggested this to and ask that they use
> Babel, or something similar, instead? 

Yes, of course I can: I've tried to build a stable communication channel with them.

I've also inserted babel in my building workflow as a static transpiling step for the next iteration of that production code of mine I've mentioned, but I wonder if there's some documentation (which I couldn't find from a superficial search) about optimizing its options according to the actual capabilities of the target engine (e.g. V8 vs Spidermonkey).

Anyway I think we should publish some dev docs about our babel/WebExtensions story.

Comment 7

[Kris Maglione [:kmag]]

(In reply to Giorgio Maone from comment #6)
> I've also inserted babel in my building workflow as a static transpiling
> step for the next iteration of that production code of mine I've mentioned,
> but I wonder if there's some documentation (which I couldn't find from a
> superficial search) about optimizing its options according to the actual
> capabilities of the target engine (e.g. V8 vs Spidermonkey).
> 
> Anyway I think we should publish some dev docs about our babel/WebExtensions
> story.

Fair enough. I'll do some research and try to have something up on MDN this week.

Comment 8

[Kris Maglione [:kmag]]

Created https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Tips#Using_advanced_JavaScript_features_from_ECMAScript_6_and_7

Comment 9

[Kris Maglione [:kmag]]

Attachment: MozReview Request: Bug 1213632: Prevent WebExtensions from using versioned JavaScript. r?billm

Bug 1213632: Prevent WebExtensions from using versioned JavaScript. r?billm

Comment 10

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

Comment on attachment 8678409 [details]
MozReview Request: Bug 1213632: Prevent WebExtensions from using versioned JavaScript. r?billm

https://reviewboard.mozilla.org/r/23203/#review20845

Please file a bug to remove this code once we resolve the relevant ES6 issues and remove JS versioning.

::: toolkit/components/extensions/test/mochitest/test_ext_jsversion.html:13
(Diff revision 1)
> +<script type="application/javascript;version=1.8">

Hehehe

::: toolkit/components/extensions/test/mochitest/test_ext_jsversion.html:37
(Diff revision 1)
> +        browser.test.log("got message");

Identation is messed up here.

::: toolkit/mozapps/extensions/AddonContentPolicy.cpp:105
(Diff revision 1)
> +  if (!(NS_SUCCEEDED(aContentLocation->SchemeIs("moz-extension", &equals)) && equals ||

Let's not rely on people knowing the relative precedence of && and ||. Please use parens.

Comment 11

[Kris Maglione [:kmag]]

https://reviewboard.mozilla.org/r/23203/#review20845

> Hehehe

Heh. Yeah, I almost added a comment about that. :)

> Identation is messed up here.

Intentional. It was so I'd remember to remove it before committing. Clearly it didn't work, though.

> Let's not rely on people knowing the relative precedence of && and ||. Please use parens.

Yeah, try refused to build it on some platforms without parens, anyway, so I already had to add them.

Comment 12

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/fx-team/rev/f7c14dcb32c8d1388c024ca781376f331a24c7d7
Bug 1213632: Prevent WebExtensions from using versioned JavaScript. r=billm

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f7c14dcb32c8

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/f7c14dcb32c8

Comment 15

[Carsten Book [:Tomcat]]

removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion