Repair and whitelisting for IE 11.

* IE 11 has a native WeakMap, but it silently fails to accept frozen
  keys. Our DoubleWeakMap patch can handle that, but had to be taught
  about the exact problem.
* IE 11's typed arrays' prototypes have zero-length ArrayBuffers in
  .buffer data properties. This is harmless but was rejected; we now
  have a 'maybeAccessor' whitelist symbol. ('accessor' is gone because
  it has no uses; we can restore it in the future if needed).

There are still Caja test failures in IE 11; these changes merely
allow SES startup to succeed.

@r5650

[MarkM, 2013-12-20 01:00:26]

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
File src/com/google/caja/ses/WeakMap.js (right):

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
src/com/google/caja/ses/WeakMap.js:157: // IE 11 bug: WeakMaps silently fail to
store frozen objects.
For this and the other tests in this file that check for expected patterns of
breakage, does it make any sense to place the tests themselves in repairES5 and
just check the outcome of the tests here?

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
src/com/google/caja/ses/WeakMap.js:165: return;
codereview is rendering a red dot in the first column of this line, but I have
no idea what this means. Is this something other than a plain ascii space?

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
src/com/google/caja/ses/WeakMap.js:581: if (!hmap.has(key)) {
What does this do on IE11:

var k = {};
hmap.set(k, 1);
Object.freeze(k);
hmap.set(k, 2);
alert(hmap.get(k));

If it alerts 1 because the second set silently failed, then your code won't
work, since the has test above will be fooled into thinking the set worked.

[kpreid2, 2013-12-20 18:36:19]

No new snapshot, but need some input on which direction to go (see both long
comments).

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
File src/com/google/caja/ses/WeakMap.js (right):

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
src/com/google/caja/ses/WeakMap.js:157: // IE 11 bug: WeakMaps silently fail to
store frozen objects.
On 2013/12/20 01:00:26, MarkM wrote:
> For this and the other tests in this file that check for expected patterns of
> breakage, does it make any sense to place the tests themselves in repairES5
> and just check the outcome of the tests here?

Yes, it very much does; I am uncomfortable with these ad-hoc tests. The problem
is that repairES5 cannot _perform the repair_ and so it would have to either
inappropriately consider the problem safe (which it isn't; this is very much an
UNSAFE_SPEC_VIOLATION except insofar as there is not yet any ratified
specification for WeakMap) or consider it unsafe and then end up aborting due to
ses.ok checks.

We have accumulated other cases similar to this, like the repairs that can't be
verified until startSES has frozen things. I propose to leave this alone for now
and then _in a separate change_, refactor repairES5 to enable these sorts of
operations.

Specifically, repairES5 will be able to understand repairs and tests being
performed after its own top-level execution has finished — so e.g. WeakMap.js
can perform the repair of the problem repairES5 detected, and then when we're
all done we can ask repairES5 to re-run a full set of tests.

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
src/com/google/caja/ses/WeakMap.js:165: return;
On 2013/12/20 01:00:26, MarkM wrote:
> codereview is rendering a red dot in the first column of this line, but I have
> no idea what this means. Is this something other than a plain ascii space?

It's a tab, rendered as 8 spaces. My fault, was using an
insufficiently-configured emacs to edit this. Fixed.

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
src/com/google/caja/ses/WeakMap.js:581: if (!hmap.has(key)) {
On 2013/12/20 01:00:26, MarkM wrote:
> What does this do on IE11:
> 
> var k = {};
> hmap.set(k, 1);
> Object.freeze(k);
> hmap.set(k, 2);
> alert(hmap.get(k));
> 
> If it alerts 1 because the second set silently failed, then your code won't
> work, since the has test above will be fooled into thinking the set worked.

Good question! I've tested the above case, as well as deleting and readding k or
putting k in a different WeakMap, and the behavior seems to be that an object
can live in a WeakMap iff it has been put in any WeakMap before it has been
frozen (so the above code is good).

Also, preventExtensions triggers the same behavior.

This suggests that we can perform a purely-in-repairES5 repair instead: patch
freeze and preventExtensions to insert every object in a dummy WeakMap before
actually freezing. This seems like a superior approach to the current one.

I wonder which way would have better performance — having every object having
been in a WeakMap _might_ trigger some kind of permanent slow-path behavior
(possibly affecting GC traversal) of the object.

Do you think we should pursue the alternative or commit this now to get things
working on trunk?

[MarkM, 2013-12-20 20:13:46]

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
File src/com/google/caja/ses/WeakMap.js (right):

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
src/com/google/caja/ses/WeakMap.js:157: // IE 11 bug: WeakMaps silently fail to
store frozen objects.
I agree that we should leave this alone for now and pursue these issues in
future CLs.

https://codereview.appspot.com/44260044/diff/1/src/com/google/caja/ses/WeakMa...
src/com/google/caja/ses/WeakMap.js:581: if (!hmap.has(key)) {
I'm fine with this submitted as is. We can revisit these issues later.

[MarkM, 2013-12-20 20:14:08]

LGTM