On 2013/07/31 06:11:21, ihab.awad wrote:
Ok, more of the puzzle has become clear to me.
I now see that caja.js is the one doing the wiring between the
"mitigation
frame" and the SES frame. So I guess caja.js can (a) say that problem
X is
"acceptable; and (b) wrap mitigateSrcGotchas in a closure that
force-sets the
options that turn on the necessary rewriting fixes for problem X. So
far so
good.
But how does caja.js *know* that these problems are indeed the case? I
guess it
should look at --
tamingWin.ses.es5ProblemReports.INCREMENT_IGNORES_FROZEN.afterFailure
? ... But that would mean that, when SES is initialized ...
tamingWin.ses.ok()
is false. So caja.js would have to have logic that says, ok() is
false, but
that's ok.
* * *
Should we perhaps just leave this CL as-is,
+1. LGTM
and defer to a future time the
construction of a clean solution whereby mitigateGotchas can be once
and for all
put into the TCB of SES?
-1. I still hope to avoid a future in which mitigateGotchas is
necessary. But it is necessary now, so I admit this question is a bit
academic at the moment.
https://codereview.appspot.com/12029043/
--
---
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.
