Fix test-of-repair for FREEZING_BREAKS_PROTOTYPES from r5359.

test_FREEZING_BREAKS_PROTOTYPES correctly tested for the problem, but
did it in a frame other than the repaired one, so it failed to confirm
the repair was successful. Unfortunately, there is no way to do this
accurately at repairES5 time since the problem is only exhibited once
Object.prototype is frozen. Instead,

* The test applies the repair to the throwaway frame before testing, if
  and only if the repair has already been applied to this frame, thus
  satisfying the test-and-repair logic.
* startSES, as a special case, executes the test after Object.prototype
  is frozen, and the test then actually tests the SES frame, thus
  ensuring that our repair worked.

The whole thing is a horrible kludge and we should rip it out as soon
as we no longer need to support repairing this problem.

@r5360

[MarkM, 2013-04-17 20:52:54]

Please add a secondary reviewer.

[ihab.awad, 2013-04-17 20:53:14]

I'll take it.

[MarkM, 2013-04-17 20:54:58]

What actually happens when this is run on the Chrome where explicit.html fails?

[kpreid2, 2013-04-17 20:59:00]

On 2013/04/17 20:54:58, MarkM wrote:
> What actually happens when this is run on the Chrome where explicit.html
fails?

I'm not sure what you're asking about — running explicit.html again? Running
Caja?

If I run explicit.html, then initSES succeeds (at UNSAFE_SPEC_VIOLATION due to
other problems), but the AMD loader test fails because Chrome's
lazily-constructed DOM node prototypes are broken.

This last doesn't matter for Caja because we never manipulate DOM originating
from the SES frame.

[ihab.awad, 2013-04-17 21:04:17]

lgtm

lktm (looks kludgey to me)?

Thanks for fixing!

[MarkM, 2013-04-17 21:14:50]

I won't have time to review this till tonight. I'm happy for this to commit on
Ihab's lgtm. I will then review post-commit.

[MarkM, 2013-04-17 21:42:30]

Correction: I might not get to this till tomorrow night.

[MarkM, 2013-04-18 22:34:40]

Once M27 is repaired, the really kludgy parts of this will be backed out, right?
How about if I postpone the post-commit-review to what remains after those are
backed out?

[kpreid2, 2013-04-18 22:40:35]

On 2013/04/18 22:34:40, MarkM wrote:
> Once M27 is repaired, the really kludgy parts of this will be backed out,
right?
> How about if I postpone the post-commit-review to what remains after those are
> backed out?

For now, we want to support the current Chrome beta which exhibits the bug, so
we won't be reverting soon.

Also, the most kludgy parts are the parts which are necessary to run at all (or,
in the case of *this* change, necessary to have SES's standard level of
confidence in correct repair), so there is no interesting partial revert to do.

[MarkM, 2013-04-18 22:49:10]

Ok, will do.