Details
-
Bug
-
Resolution: Fixed
-
Major
-
15.9
-
None
-
Integration
-
Unknown
-
N/A
-
N/A
-
Description
Create a page with this content:
before
{{html clean="false"}}
<style>
p::before {
content: '<';
}
</style>
{{/html}}
after
Then edit this page with the WYSIWYG editor. The text after the HTML macro is lost. Now replace '<' with another character in the source wiki syntax (say '!') and try again. This time the text after the HTML macro is preserved.
The problem is in CKEditor's htmlParser and can be reproduced from the JavaScript console with:
CKEDITOR.htmlParser.fragment.fromHtml(`<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><style>
p::before {
content: "<";
}
</style></head><body><p>test</p></body></html>`)
The BODY node is completely missing from the result. Replace '<' with something else and the BODY node is properly parsed. Note that wrapping the content of the style element in a CDATA section also fixes the parsing.
AFAIK escaping the '<' in inline styles (or JavaScript) is not required, so this must be a bug in CKEditor's HTML parser which uses regular expressions to match tags, and thus it wrongly matches the '<' from the inline style as a start tag. Fixing the HTML parser is dangerous IMO, and we can't expect a fix upstream because CKEditor 4 is not supported anymore. I find it safer to modify the HTML input given to the parser.
When CKEditor is loaded it calls its HTML parser giving the inner/outer HTML of the edited DOM as input. I could modify the DOM at this point to wrap the content of all inline styles (and scripts) in a CDATA section. This should fix the CKEditor initialization, but we need to review other places where the HTML parser is called.
Attachments
Issue Links
- blocks
-
-
- Closed
-