Ticket #2395 (closed Bug: duplicate)

Opened 20 months ago

Last modified 6 months ago

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

Reported by: MarkWB Owned by:
Priority: Normal Milestone:
Component: General Version: SVN (FCKeditor)
Keywords: Confirmed IE Pending Cc:

Description

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.

Change History

Changed 20 months ago by martinkou

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.

Changed 20 months ago by martinkou

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

Changed 20 months ago by fredck

  • keywords Confirmed IE added
  • milestone FCKeditor 2.6.3 deleted

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

  • _samples/html/sample08.html

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

Changed 20 months ago by fredck

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>

Changed 20 months ago by fredck

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

Changed 8 months ago by alfonsoml

  • keywords Pending added

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)?

Changed 6 months ago by alfonsoml

  • status changed from new to closed
  • resolution set to duplicate

dup of #1537

Note: See TracTickets for help on using tickets.