remove css-history-sniff defense code

Modern browsers all implement history-sniff protection in basically
the same way Caja does, so this CL deletes the code in Caja.

This CL is for the es53 branch, because the java css sanitizer
is deleted in trunk. I'll port this to trunk in a separate CL.

css-stylesheet-tests.js has some error messages added. This is because
I moved an assertNoErrors() statement in CssRewriterTest.
Previously, CssRewriterTest only checked error messages if
css-stylesheet-tests declared a "messages" element.
I felt uncomfortable about swallowing unexpected errors,
so I modified it to always check errors, whether or not "messages"
is specified.

test-domado-special-guest had a testcase that checks that history
sniffing doesn't work. In principle, we could keep this test and
check the browser's history-sniffing defense. In practice, this
was a really complicated change, because the imaginary computed
style returned by Caja was nontrivially different from the
imaginary computed style returned by browsers. After spending
too long trying to fix the test, I decided to just delete it
instead, since it's not really checking Caja code.

[kpreid2, 2013-11-27 17:46:09]

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/lang/css/C...
File src/com/google/caja/lang/css/CssPropBit.java (right):

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/lang/css/C...
src/com/google/caja/lang/css/CssPropBit.java:33: // 32 is an obsolete flag
HISTORY_INSENSITIVE
Please add a comment explaining what the intended disposition is: Is this bit
position
(a) never to be used again,
(b) held simply to avoid unnecessarily renumbering other flags, or
(c) to be left unused for a version-skew-avoiding time period, and then
available for use later?

As it is, the comment doesn't indicate how future developers should treat 32 and
256.

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/plugin/dom...
File src/com/google/caja/plugin/domado.js (right):

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/plugin/dom...
src/com/google/caja/plugin/domado.js:3572: var safeSelectors =
sanitizeCssSelectors(
Why this renaming? The selector is virtualized, which means that e.g. "foo" is
rewritten to "caja-v-foo". This concept is independent of history-sensitivity.

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/plugin/san...
File src/com/google/caja/plugin/sanitizecss.js (right):

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/plugin/san...
src/com/google/caja/plugin/sanitizecss.js:415: *    an empty array. (The second
used to be history-sensitive selectors.)
File an issue to later clean this up by eliminating the tuple and empty array,
marked as an API change?

https://codereview.appspot.com/33640043/diff/1/tests/com/google/caja/plugin/C...
File tests/com/google/caja/plugin/CssRewriterTest.java (right):

https://codereview.appspot.com/33640043/diff/1/tests/com/google/caja/plugin/C...
tests/com/google/caja/plugin/CssRewriterTest.java:171: assertNoErrors();
+1

[felix8a, 2013-11-28 03:15:32]

Modern browsers all implement history-sniff protection in basically
the same way Caja does, so this CL deletes the code in Caja.

This CL is for the es53 branch, because the java css sanitizer
is deleted in trunk. I'll port this to trunk in a separate CL.

css-stylesheet-tests.js has some error messages added. This is because
I moved an assertNoErrors() statement in CssRewriterTest.
Previously, CssRewriterTest only checked error messages if
css-stylesheet-tests declared a "messages" element.
I felt uncomfortable about swallowing unexpected errors,
so I modified it to always check errors, whether or not "messages"
is specified.

test-domado-special-guest had a testcase that checks that history
sniffing doesn't work. In principle, we could keep this test and
check the browser's history-sniffing defense. In practice, this
was a really complicated change, because the imaginary computed
style returned by Caja was nontrivially different from the
imaginary computed style returned by browsers. After spending
too long trying to fix the test, I decided to just delete it
instead, since it's not really checking Caja code.

[felix8a, 2013-11-28 03:16:15]

new snapshot

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/lang/css/C...
File src/com/google/caja/lang/css/CssPropBit.java (right):

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/lang/css/C...
src/com/google/caja/lang/css/CssPropBit.java:33: // 32 is an obsolete flag
HISTORY_INSENSITIVE
On 2013/11/27 17:46:09, kpreid2 wrote:
> Please add a comment explaining what the intended disposition is: Is this bit
> position
> (a) never to be used again,
> (b) held simply to avoid unnecessarily renumbering other flags, or
> (c) to be left unused for a version-skew-avoiding time period, and then
> available for use later?
> 
> As it is, the comment doesn't indicate how future developers should treat 32
and
> 256.

I have no idea how future developers should treat 32 and 256. All of the options
you describe sound plausible, and I think it's best to defer judgement to
whoever it is that wants to add a flag in the future. I guess I can add a
comment saying, "No idea what you should do if you want to add a flag", but that
seems pointless?

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/plugin/dom...
File src/com/google/caja/plugin/domado.js (right):

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/plugin/dom...
src/com/google/caja/plugin/domado.js:3572: var safeSelectors =
sanitizeCssSelectors(
On 2013/11/27 17:46:09, kpreid2 wrote:
> Why this renaming? The selector is virtualized, which means that e.g. "foo" is
> rewritten to "caja-v-foo". This concept is independent of history-sensitivity.

They're not just virtualized, they're also filtered. Neither "safeSelectors" nor
"virtualizedSelectors" is really accurate. I'll rename to "sanitizedSelectors".

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/plugin/san...
File src/com/google/caja/plugin/sanitizecss.js (right):

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/plugin/san...
src/com/google/caja/plugin/sanitizecss.js:415: *    an empty array. (The second
used to be history-sensitive selectors.)
On 2013/11/27 17:46:09, kpreid2 wrote:
> File an issue to later clean this up by eliminating the tuple and empty array,
> marked as an API change?

I can't find any external refs to sanitizeCssSelectors. I'll just change the API
and rename it, so that anyone depending on it will break visibly.

[kpreid2, 2013-11-28 03:23:22]

LGTM

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/lang/css/C...
File src/com/google/caja/lang/css/CssPropBit.java (right):

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/lang/css/C...
src/com/google/caja/lang/css/CssPropBit.java:33: // 32 is an obsolete flag
HISTORY_INSENSITIVE
On 2013/11/28 03:16:16, felix8a wrote:
> I have no idea how future developers should treat 32 and 256. All of the
> options you describe sound plausible, and I think it's best to defer
> judgement to whoever it is that wants to add a flag in the future. I guess
> I can add a comment saying, "No idea what you should do if you want to
> add a flag", but that seems pointless?

Given that, I propose changing "is an obsolete flag" to "used to be a flag".
This more clearly (to me) indicates that we're merely explaining why there's a
gap in numbering.

[felix8a, 2013-11-28 03:25:54]

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/lang/css/C...
File src/com/google/caja/lang/css/CssPropBit.java (right):

https://codereview.appspot.com/33640043/diff/1/src/com/google/caja/lang/css/C...
src/com/google/caja/lang/css/CssPropBit.java:33: // 32 is an obsolete flag
HISTORY_INSENSITIVE
On 2013/11/28 03:23:22, kpreid2 wrote:
> On 2013/11/28 03:16:16, felix8a wrote:
> > I have no idea how future developers should treat 32 and 256. All of the
> > options you describe sound plausible, and I think it's best to defer
> > judgement to whoever it is that wants to add a flag in the future. I guess
> > I can add a comment saying, "No idea what you should do if you want to
> > add a flag", but that seems pointless?
> 
> Given that, I propose changing "is an obsolete flag" to "used to be a flag".
> This more clearly (to me) indicates that we're merely explaining why there's a
> gap in numbering.

ok, that works for me

[felix8a, 2013-11-28 05:48:26]

@r5641 on es53 branch
@r5642 on trunk