On 2013/07/13 04:24:01, kpreid2 wrote:
https://codereview.appspot.com/10075043/diff/86001/src/com/google/caja/ses/StringMap.js
File src/com/google/caja/ses/StringMap.js (right):
https://codereview.appspot.com/10075043/diff/86001/src/com/google/caja/ses/StringMap.js#newcode20
src/com/google/caja/ses/StringMap.js:20: * @overrides ses
On 2013/07/13 04:18:47, MarkM wrote:
> Doing as suggested (patch 14) broke runtests, apparently detecting
the kind of
> inconsistency you raised. With patch 15, which chains tests
analogously to the
> original, runtests completes successfully. Not sure why yet.
That's a bit vague. Which of the objects in the chain is missing? (The
error
should have a relevant property name.) Or more generally, which tests
fail? What
does the Chrome console show for those which do?
The problem is that some tests test that things fail clearly when
repairES5.js fails in various ways (test-ses.html). When the try/catch
at the bottom of repairES5 takes the catch branch, it will not
initialize es5ProblemReports to not get initialized, causing the revised
StringMap to fail uncleanly. Patch 16 fixes StringMap to only check the
problemReports if ses.ok(). Additionally, if no ses, or if !ses.ok(), or
if the specific problem is indicated, in all these cases it assumes
Object.create might be broken and takes the more conservative route.
This is a minor improvement over the pre-CL state, though I expect it
will never matter.
https://codereview.appspot.com/10075043/
--
---
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.
