No longer requires poison on each function

https://code.google.com/p/google-caja/issues/detail?id=1947 reports
that SES does not work on FF34. The reason is that FF now (at least
approximately) implements
https://bugs.ecmascript.org/show_bug.cgi?id=3113#c18 , where
Function.prototype has deletable .caller and .argument accessor
properties, but no other functions have these as own properties. In
this situation, the safest thing to do is just delete these from
Function.prototype, and thereafter not treat these names as special.

[MarkM, 2014-12-14 09:45:26]

https://code.google.com/p/google-caja/issues/detail?id=1947 reports
that SES does not work on FF34. The reason is that FF now (at least
approximately) implements
https://bugs.ecmascript.org/show_bug.cgi?id=3113#c18 , where
Function.prototype has deletable .caller and .argument accessor
properties, but no other functions have these as own properties. In
this situation, the safest thing to do is just delete these from
Function.prototype, and thereafter not treat these names as special.

[kpreid2, 2014-12-14 17:33:32]

https://codereview.appspot.com/188160043/diff/20001/src/com/google/caja/ses/r...
File src/com/google/caja/ses/repairES5.js (right):

https://codereview.appspot.com/188160043/diff/20001/src/com/google/caja/ses/r...
src/com/google/caja/ses/repairES5.js:34: * //provides ses.noFuncPoison
By the way, I think it is a mistake to have internal-use properties and external
ones mixed up on the 'ses' object. We should consider refactoring so all of the
hookup glue is something like "ses.internal.verifyStrictFunctionBody" and so on.

This would be aligned with your previously-expressed plan (IIRC) to rename
"cajaVM" to "ses".

This shouldn't be part of this change, of course — just want to keep the thought
alive.

https://codereview.appspot.com/188160043/diff/20001/src/com/google/caja/ses/r...
src/com/google/caja/ses/repairES5.js:2686: return
Object.getOwnPropertyDescriptor(arguments, 'caller').get;
Given that this had to be changed, it seems possibly valuable to have a
self-test that the resulting object is actually what it should be (at least that
it is a function).

[kpreid2, 2014-12-14 17:33:54]

LGTM
(forgot to say in previous message)

[MarkM, 2014-12-15 01:17:19]

https://code.google.com/p/google-caja/issues/detail?id=1947 reports
that SES does not work on FF34. The reason is that FF now (at least
approximately) implements
https://bugs.ecmascript.org/show_bug.cgi?id=3113#c18 , where
Function.prototype has deletable .caller and .argument accessor
properties, but no other functions have these as own properties. In
this situation, the safest thing to do is just delete these from
Function.prototype, and thereafter not treat these names as special.

[MarkM, 2014-12-15 01:21:26]

https://codereview.appspot.com/188160043/diff/20001/src/com/google/caja/ses/r...
File src/com/google/caja/ses/repairES5.js (right):

https://codereview.appspot.com/188160043/diff/20001/src/com/google/caja/ses/r...
src/com/google/caja/ses/repairES5.js:34: * //provides ses.noFuncPoison
On 2014/12/14 17:33:31, kpreid2 wrote:
> By the way, I think it is a mistake to have internal-use properties and
external
> ones mixed up on the 'ses' object. We should consider refactoring so all of
the
> hookup glue is something like "ses.internal.verifyStrictFunctionBody" and so
on.
> 
> This would be aligned with your previously-expressed plan (IIRC) to rename
> "cajaVM" to "ses".
> 
> This shouldn't be part of this change, of course — just want to keep the
thought
> alive.

Acknowledged.

https://codereview.appspot.com/188160043/diff/20001/src/com/google/caja/ses/r...
src/com/google/caja/ses/repairES5.js:2686: return
Object.getOwnPropertyDescriptor(arguments, 'caller').get;
On 2014/12/14 17:33:32, kpreid2 wrote:
> Given that this had to be changed, it seems possibly valuable to have a
> self-test that the resulting object is actually what it should be (at least
that
> it is a function).

Done. In looking at this, I realized that we weren't testing that the
[[ThrowTypeError]] object is unique, which, btw, it isn't on FF34 until the
noPoison test cleans things up. So now tests this as well.

(I tested the test by temporarily turning off one of the deletes in the noPoison
test and saw that the NOT_UNIQUE test reported the problem appropriately.)

[kpreid2, 2014-12-15 02:19:36]

LGTM