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

NEW
Unassigned

Status

()

defect
4 years ago
4 years ago

People

(Reporter: zwol, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox41 affected)

Details

Reporter

Description

4 years ago
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.
You need to log in before you can comment on or make changes to this bug.