If you have the HTML corrector filter enabled (e.g. using the Full HTML format that ships with Drupal) and create content containing e.g. <div></div> or <iframe></iframe>, the filter will transform these into a single self-closed tag, e.g. <div /> or <iframe />.
This is incorrect; not all HTML tags are allowed to be self-closed like that.
A practical example where this causes a problem (and where I discovered the bug) is if you try to paste an embedded Google Map into a textarea. This uses an iframe, and when the filter attempts to self-close that tag for you, it causes all HTML content on the page that occurs after the iframe to not be rendered at all.
We should either have a list of tags that the HTML corrector should not self-close, or perhaps have it not self-close anything? (Its purpose is only to make sure the HTML is valid, and getting rid of existing closing tags doesn't seem relevant for that.)
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | filter-html-corrector-766332-4.patch | 6.98 KB | David_Rothstein |
| #2 | filter-html-corrector-766332-2.patch | 6.23 KB | David_Rothstein |
Comments
Comment #1
David_Rothstein commentedLooking into it a bit more, this is a regression from D6.
The fundamental cause appears to be that in D7 this filter is using XML-related functions to output XHTML. Note that a fix/workaround for this kind of issue is provided here:
http://www.php.net/manual/en/domdocument.savexml.php#95252
Comment #2
David_Rothstein commentedThis is tricky stuff, but here is a patch that should solve it (with documentation and tests).
Comment #4
David_Rothstein commentedFixing those.
Comment #5
pwolanin commentedThis is at least partially duplicate to #721536: HTML corrector filter has problems with unescaped CDATA and incorrectly closed tags
Comment #6
David_Rothstein commentedOops, yeah...
I changed the title of that issue to reflect the (new) topic that it apparently evolved into - the out of date title was why I missed it - and moved some of the tests I wrote over to that one.