Reverse accidental enabling of 'use strict' in closure compiler

third_party/closure_compiler/closure_args.gni

Index: third_party/closure_compiler/closure_args.gni
diff --git a/third_party/closure_compiler/closure_args.gni b/third_party/closure_compiler/closure_args.gni
index c8862316a9c746eda828a783caaf608b8dc88035..74a935bc1bfec1e1101fcbf6c2903d8a3d8f6451 100644
--- a/third_party/closure_compiler/closure_args.gni
+++ b/third_party/closure_compiler/closure_args.gni
@@ -53,6 +53,7 @@ minifying_closure_args = [
 
   "language_in=ECMASCRIPT_NEXT",
   "language_out=ECMASCRIPT6",
+  "emit_use_strict=false",

[dpapad, 2017/06/05 17:31:31]

Can you elaborate a bit on what is the exact problem caused by "use strict"? In
general "use strict" makes JS usage more sane, so I would prefer
 - keeping it
 - If we can't keep it, figure out exactly why.

 If some code fails in strict mode, this usually indicaten some other problems
that can be fixed alternatively.

Specifically see
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode,
section "Converting mistakes into errors"

[wychen, 2017/06/05 17:35:08]

I agree enabling "use strict" is the right direction for us. However, I believe
we've turned this on by accident and caused regressions. See crbug.com/728655.

We can turn it on after fixing the known issues.

[dpapad, 2017/06/05 17:51:23]

I see.  Can you file a bug listing the known issues and add a TODO pointing to
this bug here? I am hoping that this would increase the possibility of this
issue being addressed in the future (FWIW the phrasing in the bug makes it sound
that it  won't be fixed anytime soon).

Also, what is the difference between "emit_use_strict" and "strict_mode_input"?
The commit at
https://github.com/google/closure-compiler/commit/5279eb46b805f4a8c8d066a0b6d...
suggests that strict_mode_input should be used to opt out of the new default
behavior.

[wychen, 2017/06/05 18:25:56]

I'll add a TODO.

The thing I worry the most is the testing coverage. "use strict" only changes
the runtime behavior, and we might not have exercised them enough in our
automated tests.  Many of the JS is used in the web UI, and that's not where our
coverage is best.

The only known issue is documented in that bug (dom distiller). This might be a
bit ironic since some of the "use strict" violations come from code generated by
(older version of) closure_compiler.
I tried strict_mode_input=false but somehow it didn't remove the "use strict"
output.

[wychen, 2017/06/05 20:21:54]

Done.

 ]
 
 # For compatibility with old uses.