[Blink, Webkit, IE11] Comments inside iframe tags get messed up

[Ingo]

How to reproduce.

1. Go to the demo Page ​http://ckeditor.com/demo#full
2. Switch to source mode
3. Delete all the content
4. enter the following content

   <iframe src="http://google.de"><!-- Hello -->This is a test</iframe>
   

5. switch to wysiwyg mode
6. switch back to source mode enter the comment is messed up

<iframe src="http://google.de">&lt;!--{cke_protected}{C}%3C!%2D%2D%20Hello%20%2D%2D%3E--&gt;This is a test</iframe>

[Piotrek Koszuliński]

This is a nasty issue and I saw recently more reports about cke_protected being left in data. Let's investigate this in 4.3.3.

[Jakub Ś]

@Reinmar I'm very happy that you have put milestone for comments issue although you may remove it after I include all the tickets.

This is an old issue(s) that concerns HTML comments and {cke_protected}. Element iframe is not the only case where this happens. This is one of many examples.

Other HTML comments problems: #6709, #8216, #8129, #8640.

Other cke-protected problems: #7805, #7826, #9205

I assume that it isn’t good idea to fix just one particular issue but handle whole problem.

Please have a look at #9205. There is an old patch which, at a time, was fixing #9205, #7805, #7826, #8216.

[Piotrek Koszuliński]

Thanks Kuba for this research. I'll investigate this and see if by a chance all or most of these issues cannot be fixed at once.

[Macsim Catalin]

I had this issue and it was fixed by replacing the regex from the original patch in htmldataprocessor.js.

 // Different protection pattern is used for those that
 // live in attributes to avoid from being HTML encoded.
-return data.replace( /(['"]).*?\1/g, function( match ) {
+return data.replace( /<[^>]*(['"]).*?\1*>/g, function( match ) {

[Piotrek Koszuliński]

This turned out to be very interesting issue. It's not a CKEditor bug first of all. Check how browsers encode content of an iframe - you can do it using test-iframe-innerhtml.html​ sample.

• Firefox leaves it as it is.
• Chrome and IE11 encodes it, so a comment becomes <--foo-->.
• IE8 does some weird things as usual.

Which behaviour is correct? It turns out most likely Chrome's and IE11's. It's explained in ​HTML5 spec that iframe's content is parsed as a text.

Descendants of iframe elements represent nothing. (In legacy user agents that do not support iframe elements, the contents would be parsed as markup that could act as fallback content.)

When used in HTML documents, the allowed content model of iframe elements is text, except that invoking the HTML fragment parsing algorithm with the iframe element as the context element and the text contents as the input must result in a list of nodes that are all phrasing content, with no parse errors having occurred, with no script elements being anywhere in the list or as descendants of elements in the list, and with all the elements in the list (including their descendants) being themselves conforming.

The iframe element must be empty in XML documents.

The HTML parser treats markup inside iframe elements as text.

However, this doesn't explain how CKEditor should handle the situation. I would say that it cannot follow the spec, because:

1. You load <iframe>f<!--x-->x</iframe>
2. It becomes <iframe>f&lt;--x--&gt;x</iframe>
3. You load this and it becomes <iframe>f&amp;lt;--x--&amp;gt;x</iframe>

So CKEditor should preserve the original content... or strip everything more than text. Both solutions are not easy and since setting content of an iframe is deprecated because useless, this ticket has low priority.

[Piotrek Koszuliński]

#11223 fixed part of this issue ({cke_protected} does not leak any more). Second part is related to browsers encoding content of an <iframe>. As I explained in comment:6 IE11's and Chrome's behaviour is weird and CKEditor would have to override it. It's unlikely that we'll work on this issue considering the fact that using comments inside iframe tags is useless. In fact, I'd close this issue, but let's keep it open for some time. I'm curious in which direction browsers will go with this.

[Piotrek Koszuliński]

Separate ticket for comments in <title> was reported: #11958.