40 bytes, text/x-review-board-request
+++ 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.
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.
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.
Summary: Suggest using Babel when WebExtensions attempt to use versioned script tags or unsupported ES6 features → Prevent WebExtensions attempts to use versioned script tags
I did a quick test, and it looks like we'll be able to do this fairly easily with a content policy.
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.
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.
(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.
(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.
Attachment #8678409 - Flags: review?(wmccloskey)
Attachment #8678409 - Flags: review?(wmccloskey) → review+
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
status-b2g-v2.5: --- → fixed
removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion
status-b2g-v2.5: fixed → ---
You need to log in before you can comment on or make changes to this bug.