https://codereview.appspot.com/10181043/diff/41001/src/com/google/caja/ses/exportsToSES.js
File src/com/google/caja/ses/exportsToSES.js (right):
https://codereview.appspot.com/10181043/diff/41001/src/com/google/caja/ses/exportsToSES.js#newcode30
src/com/google/caja/ses/exportsToSES.js:30: "use strict";
On 2013/07/09 16:08:48, kpreid2 wrote:
single quotes
Done. But sometime we should argue about this. "use strict"; doesn't
mean what a string literal normally means. Rather, it is a pragma that
happens to have the syntax of a string literal in order not to break on
ES3 browsers. Given that we always use single quotes for normal string
literals, I think we should consistently use double quotes for these
pragmas. (Also for "use asm".)
https://codereview.appspot.com/10181043/diff/41001/src/com/google/caja/ses/repairES5.js
File src/com/google/caja/ses/repairES5.js (right):
https://codereview.appspot.com/10181043/diff/41001/src/com/google/caja/ses/repairES5.js#newcode730
src/com/google/caja/ses/repairES5.js:730: // This case is likely
sympomatic of an attack. But the
On 2013/07/09 16:08:48, kpreid2 wrote:
"symptomatic"
Done.
https://codereview.appspot.com/10181043/diff/41001/src/com/google/caja/ses/repairES5.js#newcode756
src/com/google/caja/ses/repairES5.js:756: newSrc =
ses.mitigateSrcGotchas(funcBodySrc,
On 2013/07/09 16:08:48, kpreid2 wrote:
Somewhere it should be documented that caja.js swaps out this function
and
therefore uses of it must not close over the value at init time.
(And if that weren't the case, I would tell you to close over the
value so we're
not doing an extra property lookup at runtime, and so that the
non-frozen 'ses'
object is irrelevant after initialization.)
Done.
https://codereview.appspot.com/10181043/diff/41001/src/com/google/caja/ses/repairES5.js#newcode764
src/com/google/caja/ses/repairES5.js:764: safeError = new
Error(error.message);
On 2013/07/09 16:08:48, kpreid2 wrote:
Would it be worthwhile to copy SyntaxErrors as SyntaxErrors here?
Because of how ses.mitigateSrcGotchas works, unfortunately not. If the
actual parsing throws at all, ses.mitigateSrcGotchas simply logs the
text of the error and returns a string that, if evaluated, will throw a
SyntaxError with a non-specific diagnostic.
The better plan would be to improve the API of ses.mitigateSrcGotchas.
But not in this CL.
https://codereview.appspot.com/10181043/diff/41001/src/com/google/caja/ses/repairES5.js#newcode771
src/com/google/caja/ses/repairES5.js:771: if (newSrc !== funcBodySrc) {
On 2013/07/09 16:08:48, kpreid2 wrote:
Please add a comment explaining why this comparison is meaningful.
It's not
obvious:
If ses.mitigateSrcGotchas (with these parameters) is expected to
return the
input source, under what circumstances would it _not_ do so, and what
does it
return instead? If it is expected to transform the input source, under
what
circumstances would it return a result equal to the input?
Done.
https://codereview.appspot.com/10181043/diff/41001/src/com/google/caja/ses/repairES5.js#newcode772
src/com/google/caja/ses/repairES5.js:772: throw new SyntaxError("Failed
to parse program");
On 2013/07/09 16:08:48, kpreid2 wrote:
single quotes
Done. And several others in the file. I also noticed and removed some
redundant "use strict" directives. They were redundant because they were
in functions already lexically nested within strict code.
https://codereview.appspot.com/10181043/
--
---
You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
