fix various domita test issues

This fixes:

bug 1131 - bridal constructClone doesn't set the "class"
  attribute properly on IE[67].

bug 1140 - testUseMap fails on various browsers, because it's
  doing un-normalized html comparison.  after this change, it
  still fails on IE[67] because you can't set an element's @name
  after it's created.

bug 1142 - two cloneNode tests fail on IE8-std.

bug 1143 - _testSideEffectTestFramework fails on IE.

bug 1162 - Array.slice behaves differently on various browsers
  when the end arg === undefined.

bug 1168 - "Ready for testing" box never turns green on IE[67].

[MikeSamuel, 2009-11-19 23:54:33]

http://codereview.appspot.com/157093/diff/1/5
File src/com/google/caja/cajita.js (right):

http://codereview.appspot.com/157093/diff/1/5#newcode98
src/com/google/caja/cajita.js:98: if (end === void 0) { end = self.length; }
Ok, so bug 1162 says that not supplying start doesn't cause problemsm but
supplying undefined for end screws up firefox iff start is supplied.
Is there a reason not to infer 0 for start as well?

http://codereview.appspot.com/157093/diff/1/4
File src/com/google/caja/plugin/bridal.js (right):

http://codereview.appspot.com/157093/diff/1/4#newcode136
src/com/google/caja/plugin/bridal.js:136: bridal.setAttribute(clone,
attr.nodeName, attr.nodeValue);
cool

http://codereview.appspot.com/157093/diff/1/2
File tests/com/google/caja/plugin/domita_test.html (right):

http://codereview.appspot.com/157093/diff/1/2#newcode69
tests/com/google/caja/plugin/domita_test.html:69: s.text = 'globalSideEffect()';
why text?
not nodeValue or innerHTML?

http://codereview.appspot.com/157093/diff/1/2#newcode167
tests/com/google/caja/plugin/domita_test.html:167: bridal.setAttribute(e,
'class', 'readytotest');
OK

http://codereview.appspot.com/157093/diff/1/3
File tests/com/google/caja/plugin/domita_test_untrusted.html (right):

http://codereview.appspot.com/157093/diff/1/3#newcode119
tests/com/google/caja/plugin/domita_test_untrusted.html:119: <p>After
<code>document.write</code></p>
This shouldn't cause a bug.  If it does, it's a bug in the Parser.

http://codereview.appspot.com/157093/diff/1/3#newcode659
tests/com/google/caja/plugin/domita_test_untrusted.html:659: var name =
m[1].toLowerCase();
OK

http://codereview.appspot.com/157093/diff/1/3#newcode1014
tests/com/google/caja/plugin/domita_test_untrusted.html:1014: var html =
el.innerHTML.replace(new RegExp('[\\r\\n]\\s*', 'g'), '');
I'm fine if this is aggressive canonicalization since we're not testing
whitespace here, but aren't newlines and spaces usually collapsed to a single
space?

http://codereview.appspot.com/157093/diff/1/3#newcode1828
tests/com/google/caja/plugin/domita_test_untrusted.html:1828: //assertArray([9],
Array.slice([9], null, void 0), '([9], null, void 0)');
I'm confused.  Do we correct the problem and follow ES5?
Is there a bug filed against firefox?

http://codereview.appspot.com/157093/diff/1/3#newcode2388
tests/com/google/caja/plugin/domita_test_untrusted.html:2388: { nodeName:
'class', nodeValue: 'cloneable' }
cool

http://codereview.appspot.com/157093/diff/1/3#newcode2411
tests/com/google/caja/plugin/domita_test_untrusted.html:2411: { nodeName: 'for',
nodeValue: 'x' }
cool

http://codereview.appspot.com/157093/diff/1/3#newcode3173
tests/com/google/caja/plugin/domita_test_untrusted.html:3173: + '
usemap="#foo-xyz___"'
cool

[felix8a, 2009-11-20 00:12:09]

http://codereview.appspot.com/157093/diff/1/5
File src/com/google/caja/cajita.js (right):

http://codereview.appspot.com/157093/diff/1/5#newcode98
src/com/google/caja/cajita.js:98: if (end === void 0) { end = self.length; }
On 2009/11/19 23:54:33, MikeSamuel wrote:
> Ok, so bug 1162 says that not supplying start doesn't cause problemsm but
> supplying undefined for end screws up firefox iff start is supplied.
> Is there a reason not to infer 0 for start as well? 

I was thinking that it's unnecessary code if the browser's Array.prototype.slice
does the right thing, but I just realized I'm not checking the weird failure
cases on IE, so I'll fix it.

http://codereview.appspot.com/157093/diff/1/2
File tests/com/google/caja/plugin/domita_test.html (right):

http://codereview.appspot.com/157093/diff/1/2#newcode69
tests/com/google/caja/plugin/domita_test.html:69: s.text = 'globalSideEffect()';
On 2009/11/19 23:54:33, MikeSamuel wrote:
> why text?
> not nodeValue or innerHTML?

setting s.innerHTML causes a runtime error on IE.  s.text works on all browsers
I tried.  I didn't try nodeValue.

http://codereview.appspot.com/157093/diff/1/3
File tests/com/google/caja/plugin/domita_test_untrusted.html (right):

http://codereview.appspot.com/157093/diff/1/3#newcode119
tests/com/google/caja/plugin/domita_test_untrusted.html:119: <p>After
<code>document.write</code></p>
On 2009/11/19 23:54:33, MikeSamuel wrote:
> This shouldn't cause a bug.  If it does, it's a bug in the Parser.

it affected the .innerHTML value in IE in a weird way, something about spacing. 
I wasn't sure how to normalize it in a way that wouldn't break something else. 
it seemed simpler to close the </p> to remove the whitespace issue.

http://codereview.appspot.com/157093/diff/1/3#newcode1014
tests/com/google/caja/plugin/domita_test_untrusted.html:1014: var html =
el.innerHTML.replace(new RegExp('[\\r\\n]\\s*', 'g'), '');
On 2009/11/19 23:54:33, MikeSamuel wrote:
> I'm fine if this is aggressive canonicalization since we're not testing
> whitespace here, but aren't newlines and spaces usually collapsed to a single
> space?

the problem is browsers seem inconsistent about whether they keep spaces or not.
 without that regexp replace, the innerHTML in IE has all sorts of extra spacing
that doesn't show in the innerHTML in other browsers.

http://codereview.appspot.com/157093/diff/1/3#newcode1828
tests/com/google/caja/plugin/domita_test_untrusted.html:1828: //assertArray([9],
Array.slice([9], null, void 0), '([9], null, void 0)');
On 2009/11/19 23:54:33, MikeSamuel wrote:
> I'm confused.  Do we correct the problem and follow ES5?
> Is there a bug filed against firefox?

yeah, I'm confused too, the problem case is IE.  will fix and clarify.
haven't filed a firefox bug  yet.

[MikeSamuel, 2009-11-20 00:37:51]

http://codereview.appspot.com/157093/diff/1/2
File tests/com/google/caja/plugin/domita_test.html (right):

http://codereview.appspot.com/157093/diff/1/2#newcode69
tests/com/google/caja/plugin/domita_test.html:69: s.text = 'globalSideEffect()';
ah.  OK

http://codereview.appspot.com/157093/diff/1/3
File tests/com/google/caja/plugin/domita_test_untrusted.html (right):

http://codereview.appspot.com/157093/diff/1/3#newcode119
tests/com/google/caja/plugin/domita_test_untrusted.html:119: <p>After
<code>document.write</code></p>
OK.  So IE just has different trailing whitespace in the HTML output.  What if
your normalization was, instead of /[\r\n]\s*/g, something that trimmed as well:
/(?:^|[\r\n])\s*|\s+$/g?

http://codereview.appspot.com/157093/diff/1/3#newcode1014
tests/com/google/caja/plugin/domita_test_untrusted.html:1014: var html =
el.innerHTML.replace(new RegExp('[\\r\\n]\\s*', 'g'), '');
Cool.  I'm fine with that.

http://codereview.appspot.com/157093/diff/1/3#newcode1828
tests/com/google/caja/plugin/domita_test_untrusted.html:1828: //assertArray([9],
Array.slice([9], null, void 0), '([9], null, void 0)');
thanks

[felix8a, 2009-11-20 03:21:01]

http://codereview.appspot.com/157093/diff/1/3
File tests/com/google/caja/plugin/domita_test_untrusted.html (right):

http://codereview.appspot.com/157093/diff/1/3#newcode119
tests/com/google/caja/plugin/domita_test_untrusted.html:119: <p>After
<code>document.write</code></p>
On 2009/11/20 00:37:51, MikeSamuel wrote:
> OK.  So IE just has different trailing whitespace in the HTML output.  What if
> your normalization was, instead of /[\r\n]\s*/g, something that trimmed as
well:
> /(?:^|[\r\n])\s*|\s+$/g?

it's not just trailing whitespace.  there are many different
whitespace anomalies in IE's innerHTML output.

I think I'll try normalizing \s+ to a single space.
just need to re-test the normalization on all the browsers.

[felix8a, 2009-11-20 03:55:19]

new snapshot.  tested it manually on ie6, ie7, ie8-compat, ie8-std, ff3.0,
ff3.5, safari4, opera10, chrome.  the only failures are ones already reported.

[MikeSamuel, 2009-11-20 07:32:24]

LGTM

http://codereview.appspot.com/157093/diff/1/3
File tests/com/google/caja/plugin/domita_test_untrusted.html (right):

http://codereview.appspot.com/157093/diff/1/3#newcode119
tests/com/google/caja/plugin/domita_test_untrusted.html:119: <p>After
<code>document.write</code></p>
On 2009/11/20 03:21:01, felix8a wrote:
> On 2009/11/20 00:37:51, MikeSamuel wrote:
> > OK.  So IE just has different trailing whitespace in the HTML output.  What
if
> > your normalization was, instead of /[\r\n]\s*/g, something that trimmed as
> well:
> > /(?:^|[\r\n])\s*|\s+$/g?
> 
> it's not just trailing whitespace.  there are many different
> whitespace anomalies in IE's innerHTML output.
> 
> I think I'll try normalizing \s+ to a single space.
> just need to re-test the normalization on all the browsers.

Don't let this stop you from submitting.  I only suggested it in case it was a
quick fix.  The code here isn't testing whitespace handling so I'm fine with the
normalization being coarse.

[felix8a, 2009-11-20 07:51:07]

@r3857