Opened 10 years ago

Last modified 10 years ago

#11442 confirmed Bug

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

Reported by: Ingo Owned by: Piotrek Koszuliński
Priority: Low Milestone:
Component: General Version:
Keywords: Cc:

Description

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>

Attachments (1)

test-iframe-innerhtml.html (629 bytes) - added by Piotrek Koszuliński 10 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 10 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.3.3
Status: newconfirmed
Version: 4.3.1

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.

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by Piotrek Koszuliński

Owner: set to Piotrek Koszuliński
Status: confirmedassigned

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.

comment:4 Changed 10 years ago by 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 ) {
Last edited 10 years ago by Macsim Catalin (previous) (diff)

comment:5 Changed 10 years ago by Piotrek Koszuliński

Summary: comments inside iframe tags get messed upComments inside iframe tags get messed up

Changed 10 years ago by Piotrek Koszuliński

Attachment: test-iframe-innerhtml.html added

comment:6 Changed 10 years ago by Piotrek Koszuliński

Status: assignedpending
Summary: Comments inside iframe tags get messed up[Blink, Webkit, IE11] Comments inside iframe tags get messed up

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 &lt;--foo--&gt;.
  • 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.

Last edited 10 years ago by Piotrek Koszuliński (previous) (diff)

comment:7 Changed 10 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.3.3

comment:8 Changed 10 years ago by Piotrek Koszuliński

Status: pendingconfirmed

comment:9 Changed 10 years ago by Piotrek Koszuliński

Priority: NormalLow

#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.

comment:10 Changed 10 years ago by Piotrek Koszuliński

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

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy