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.