InsertHtml() can prefix an additional annoying blank paragraph with IE

[Mark Bryson]

If content being inserted is not being inserted into a block level element, but itself begins with a block level element (e.g. <p>insertion</p>), then this results in the extra blank prefixed paragraph.

Following are lines 165 through 173 (as of 07/19) of the InsertHtml() function in the 'internals/fck_ie.js' file.

	// Using the following trick, any comment in the beginning of the HTML will
	// be preserved.
	html = '<span id="__fakeFCKRemove__" style="display:none;">fakeFCKRemove</span>' + html ;

	// Insert the HTML.
	oSel.createRange().pasteHTML( html ) ;

	// Remove the fake node
	FCK.EditorDocument.getElementById('__fakeFCKRemove__').removeNode( true ) ;

This 'trick' is what I find causing the extra beginning blank paragraph. I suspect that pasteHTML() is making the HTML valid by putting the span inside of a block level element (namely a <p> tag). Then the removal only removes the span thus leaving the extra paragraph. ( <p>&nbsp;</p> )

I'd prefer having to embed a beginning comment in a tag due to omitting this trick [which is what this ends up doing in this case anyway given <!-- comment --><p>insert</p> to get <p><!-- comment --></p><p>insert</p>] than have this paragraph added when inserting a block with no comment. In other words, this 'trick' semi-fixes so few cases (none in my case) with annoying expense for many use cases.

If preserving such comments is important, then replacing 'span' with 'p' (or 'div') works in this particular case, but unacceptably breaks inline insertions. Perhaps the appropiate way should be determined by looking at the parent element. I've tried using elements that can be either block or inline elements (e.g. object), but without success. They always get treated like inline elements. (also work like span) So, unfortunately a good solution for this problem isn't as simple as merely changing the tag.

[Martin Kou]

I've tried a few times in IE6 and IE7 with sample12.html and EnterMode=BR. But I haven't been able to reproduce the bug.

The fakeFCKRemove hack is going to be removed in the newest patch in #2247, which will be committed to SVN soon.

[Martin Kou]

oops... the fakeFCKRemove in fck_ie.js is different from those being removed in #2247's patch.

[Frederico Caldeira Knabben]

I've confirmed it with IE7 with the following modification to sample08.html:

_samples/html/sample08.html

@@ -50 +50 @@
         // Check the active editing mode.
         if ( oEditor.EditMode == FCK_EDITMODE_WYSIWYG )
         {
-                // Insert the desired HTML.
-                oEditor.InsertHtml( '- This is some <a href="/Test1.html">sample<\/a> HTML -' ) ;
+                oEditor.Commands.GetCommand('SelectAll').Execute();
+                oEditor.InsertHtml( '<p>insertion</p>' );
         }
         else
                 alert( 'You must be on WYSIWYG mode!' ) ;

[Frederico Caldeira Knabben]

The problem here is not only the InsertHtml call. Is the combination of the SelectAll command and the InsertHtml call.

It looks like, when doing SelectAll and then pasteHTML in IE, the pasted data ends up inside the paragraph. So, you have this ugly thing:

<p>
    <p>insertion</p>
</p>

The above monster renders like:

<p></p>
<p>insertion</p>

To confirm this theory, with the above changes to sample08, load <h1>Test</h1> in the editor and click "Insert HTML". You will have this:

<h1>
<p>insertion</p>
</h1>
<p>&nbsp;</p>

[Frederico Caldeira Knabben]

It happens also when just calling InsertHtml( '<p>insertion</p>' ) in an empty paragraph in the middle of the text.

[Alfonso Martínez de Lizarrondo]

I have tested and it seems to working fine (IE8). I guess that it has been fixed by #1537

Can anyone still reproduce the problem (using the current nightly of FCKeditor)?

[Alfonso Martínez de Lizarrondo]

dup of #1537