New snapshot.
https://codereview.appspot.com/8806045/diff/1/src/com/google/caja/ses/repairES5.js
File src/com/google/caja/ses/repairES5.js (right):
https://codereview.appspot.com/8806045/diff/1/src/com/google/caja/ses/repairES5.js#newcode2880
src/com/google/caja/ses/repairES5.js:2880: function
repair_OBJECT_CREATE() {
On 2013/04/16 22:20:38, MarkM wrote:
This looks very much like my earlier attempt at repair that I gave up
on. The
problem is that, in the presence of this bug, many things besides
Object.create were also broken. In short, look for all the places that
mstarzinger's fix to this bug touched. If any of these are not fixed
by this
repair, and are fatal to us when unrepaired, that would be bad.
I have run the full Caja tests on Chrome Canary and everything passes
(except for the unrelated
<https://code.google.com/p/google-caja/issues/detail?id=1703>), which is
evidence things will be OK.
Reviewing the V8 changes,
<https://code.google.com/p/v8/source/detail?r=13817> is merely modifying
Object.prototype.__proto__ itself, and
<https://code.google.com/p/v8/source/detail?r=13815> touches the
following files:
apinatives.js:
This appears to be initializing the .prototype.[[Prototype]] chains of
lazily-constructed builtin constructors. I suspect that startSES's
traversal causes all of these to be instantiated before freezing
happens; and failures here would be likely to break tests.
full-codegen-*.cc:
This appears to affect __proto__ in object literals, which we do not use
nor expect our guests to be able to use -- but means that uses of such
inside of Chrome will be broken. I have reviewed such uses and they
appear to be OK, except for one use in the implementation of
getOwnPropertyNames pertaining to "interceptor properties", whatever
those are.
array.js:
This looks like it will cause .sort() of a sparse array to ignore
inherited numeric properties. I think ideally we would consider this a
SAFE_SPEC_VIOLATION and maybe even repair it (by de-holeing arrays
before sorting) later, but it won't break us or most guest code.
d8.js:
Appears to be debugger code.
math.js:
Presumably runs before SES, and if it is in fact lazy it will be
triggered by startSES's traversal.
messages.js:
The worst this will do is cause Error objects to be misprinted; I
haven't followed the full call chain but it looks like it's for
debugging and/or cross-frame stuff, so normal in-one-frame semantics are
likely preserved.
proxy.js:
A proxy derived [[Construct]] trap will fail to operate correctly; we
don't use proxies as ctors and don't expose real Proxy to guests, and we
already know we fail with Experimental JavaScript (which includes
proxies) turned on.
v8natives.js:
One of these is Object.create which we repair, and the other appears to
be early initialization code.
So, in conclusion, the only visible effect to guests (other than in
debugging them) that I can see will be on sparse arrays, which nobody
uses.
https://codereview.appspot.com/8806045/diff/1/src/com/google/caja/ses/repairES5.js#newcode2887
src/com/google/caja/ses/repairES5.js:2887: // "1. If Type(O) is not
Object or Null throw a TypeError exception."
On 2013/04/16 22:20:38, MarkM wrote:
This spec language does not correspond to testing (typeof O !==
'object').
Instead, (typeof O !== 'object' && typeof O !== 'function') would be
valid.
Or, if you check for null first, this test could be (O !== Object(O)).
The
second is arguably more robust (even if less efficient) because it
does not
depend on knowing all the typeof possibilities exhaustively.
Done.
https://codereview.appspot.com/8806045/
--
---
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.
