testScriptLoading has some bad tests

this doesn't really fix the problem, but it documents it.

[kpreid2, 2013-03-20 23:22:53]

https://codereview.appspot.com/7935043/diff/1/tests/com/google/caja/plugin/es...
File tests/com/google/caja/plugin/es53-test-domado-special-guest.html (right):

https://codereview.appspot.com/7935043/diff/1/tests/com/google/caja/plugin/es...
tests/com/google/caja/plugin/es53-test-domado-special-guest.html:601:
pass('testScriptSrcFail');
Ergh, mixing side effects into the 'predicate'.

I don't think this change fits the intent of the assertAsynchronousRequirement
mechanism, having looked it over a bit. How about this: each asynchronous
requirement is registered as a new test (or something like it, more explicitly
subsidiary) which itself passes or fails according to the async requirement
predicate?

If you'd prefer, I'll attempt the implementation of that.

https://codereview.appspot.com/7935043/diff/1/tests/com/google/caja/plugin/es...
tests/com/google/caja/plugin/es53-test-domado-special-guest.html:612: <!--
TODO(felix8a): temp disable, because test fails, unsure why.
FYI, I had a vague memory of doing something with this test, and found out that
*I* enabled it in r5110. I think it was actually working (no async failure)
then. I wonder if your async/timeout changes in r5325 changed the ordering, but
of course we wouldn't have noticed if it failed earlier.

Also, IMO, jsunitRegisterIf(false, ...) is a better strategy to disable a test
than commenting it out, because it leaves a visible artifact in the page.

[kpreid2, 2013-04-19 21:03:04]

You may close this review: The test changes are obsoleted by r5363, and I'm
working on fixing assertAsynchronousRequirement.