597393 - execCommand with insertHTML and iframe displays noframes-content

Status: RESOLVED DUPLICATE of bug 597784

(Core :: DOM: Editor, defect)

Description

[chokemachine]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729; .NET4.0E)

This bug exists in Firefox versions 3.6.9 and 3.6.10. In 3.6.8 everything works fine.
I'm working with a DIV-container where contenteditable="true" and document.designMode="on".
When executing the insertHTML command with an valid iframe-tag, like shown below in the stepts to reproduce, the resulting action is not the expected iframe, like it did in version 3.6.8, but the noframes-part "<b>no frames</b>". Even the formatting tags in this example will not be parsed.



Reproducible: Always

Steps to Reproduce:
1. create HTML document and set document.designMode="on"
2. create editable DIV like:
<div contenteditable="true" id="editor">hello world</div>
3. click into editable div (for example after "hello") and execute the following (i did it with firebug)
document.execCommand("insertHTML", false, "<iframe src='http://www.google.com' width='50' height='50'><b>no frames</b></iframe>")
Actual Results:  
when clicked after "hello" it will display the following in the DIV-container:
"hello<b>no frames</b> world"

Expected Results:  
it should have inserted an iframe node at the position after the character sequence "hello"

maybe relevant information can be that in the first version this bug is implemented the new x-frame-options were implemented at the first time as well.
because they restrict including other site by iframes the implementation could have affected something wrong?

Comment 1

[Matthias Versen [:Matti]]

do you mean bug 595176 / bug 594725 ?

Comment 2

[chokemachine]

(In reply to comment #1)
> do you mean bug 595176 / bug 594725 ?

> do you mean bug 595176 / bug 594725 ?

no, it's not about custom tags that have to be inserted.
it's about getting a visible iframe into the DIV-container instead of its noframes-content.

Comment 3

[(no longer active)]

This is by design.  Loading iframes in this way has been disabled in bug 520189 for security reasons.

Comment 4

[(no longer active)]

In fact, we're going to change this behavior in bug 597784, so that inserthtml doesn't strip anything from its input, the same way that setting innerHTML does not.  Please follow that bug for the progress of this issue.