1177546 - Tree sanitizer doesn't delete an unparseable CSS rule when that would make the sheet empty

Status: NEW

(Core :: DOM: Editor, defect, P5)

Description

[Zack Weinberg (:zwol)]

If the CSS parser recognizes at least one of the rules in a <style> sheet pasted into a contenteditable, all the rules it doesn't recognize are deleted.  But if it recognizes *none* of the rules, the original text inside the <style> tag is added to the document verbatim.  This tripped me up in bug 1035091, where a test was expecting a @-moz-document rule to be deleted:

> editor/libeditor/tests/test_bug520189.html tests, among other things, that a
> @-moz-document rule in a <style> pasted into a contenteditable does not
> survive sanitization.  I assumed that this would continue working and did
> not test it locally.  It does technically still work, but it hits an edge
> case in the sanitizer which makes the test fail.
> 
> Before the patch, the CSS parser recognizes the @-moz-document rule and
> gives the sanitizer a style sheet object containing one rule.  The sanitizer
> then throws away that rule as it's not on its whitelist, so the modified
> document ends up with an empty <style> tag, which is what the test case
> looks for.
> 
> After the patch, the CSS parser does not recognize the @-moz-document rule
> so it gives the sanitizer a style sheet object containing *zero* rules. 
> This causes the sanitizer to use the original pasted text as the contents of
> the <style> tag.  The sanitization still works in that the @-moz-document
> rule has no effect, but the test is looking at the contents of the <style>
> so it fails.

It seems to me that this is wrong and we should add an empty <style> to the document when the parser returns zero rules.

Comment 1

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.