API: GetXHTML() temporarily distorts rendering

[dustball]

Steps to reproduce:

1. Load demo page with Firefox
2. Choose "Sample 8: Editor API usage" from the drop down
3. Focus before "You are using" and hit enter 5 times
4. Click "Get Editor Contents (XHTML)"

The call returns the proper XHTML, but the text in the editor jumps.

We are implementing an autosave feature which periodically calls this function to get the XHTML and send it back to the server using XMLHTTPRequest. It works perfectly except for the dancing text ;)

[dustball]

For anyone else having this problem, I recommend using the following workaround:

var fck = FCKeditorAPI.GetInstance('content');
var xhtml = fck.EditorDocument.body.innerHTML;

[alfonsoml]

If you get the contents with body.innerHTML then you'll have very serious trouble when the content has any protected source element (comments, script) that will get lost, in links and anchors you'll get extra attributes, in flash, anchors and other special elements you'll get the fake image instead of the contents...

So that would be a really bad workaround as a general rule.

[alfonsoml]

I've looked at this and the fix doesn't look hard, but I'm not sure to touch that part of the code this way, as it generates a dependency on FCKConfig and FCKTools, and maybe there's something better, but basically it comes down to this: the new <p> in Firefox have only this content: <p><br></p> and in FCKDomTools.RTrimNode called from

FCKXHtml._AppendChildNodes = function( xmlNode, htmlNode, isBlockElement )
{
	// Trim block elements. This is also needed to avoid Firefox leaving extra
	// BRs at the end of them.
	if ( isBlockElement )
		FCKDomTools.TrimNode( htmlNode, true ) ;

all the contents of that <p> are removed so it does visually collapse.

The attached patch fixes the problem

[alfonsoml]

proposed patch

[dustball]

The proposed patch seems to work well.

[alfonsoml]

I've commited the patch in [253] so it can be better tested.

[fredck]

Sorry for not getting back to this one earlier.

While the proposed patch ([253]) made it work, it sound a little bit like a "hack", more than a fix (as noted by Alfonso himself).

FCKDomTools.RTrimNode is a tool function that must do its job as expected, without configurable (and unrelated) variations. If the fix must really be done there, then it should have a parameter to enable the FillEmptyBlocks thing, instead of checking the config internally.

The real source of the problem can be found at FCKXHtml._AppendChildNodes, with the call to FCKDomTools.TrimNode( htmlNode ). The fact is that the XHTML processor "must not" change the current HTML DOM tree. While changes on it are ok when switching to source mode, they may have an undesirable behavior when using the API.

I'm working on a fix for it now.

[fredck]

Fixed with [256].

Click here for more info about our SVN system.

[fredck]

Also [256] rolled back changes from [253].

[dustball]

Thanks, [256] works well.

[ychaouche]

Hi !

I use : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0 FCK 2.4.3 (downloaded today Friday June 15th 2007)

When I use GetXHTML in my plugin (it counts the number of characters typed), and then type something in the editing area, i get every character wrapped in <p></p> tags, sometimes spaces are suppressed. My plugin looks like this :

//Event Handler
FCKcountEventHandler = function () {
    FCKCommands.GetCommand('count').Execute();
}

//Define the command.
var FCKcount = function( maxlength  )
{
	this.MaxLength = maxlength ;
	/*document.getElementById('maxlengthtext').innerHTML=this.MaxLength;*/
}
//Execute this when invoked
FCKcount.prototype.Execute = function (){
    var length = 0;
    var content = FCK.GetXHTML( FCKConfig.FormatSource );
}

FCK.Events.AttachEvent( 'OnSelectionChange', FCKcountEventHandler ) ;
FCKCommands.RegisterCommand('count',new FCKcount(FCK.Config['MaxLength']) );

//First time execution 
FCKCommands.GetCommand('count').Execute();

When i comment the FCK.GetXHTML tag, everything returns to normal. I applied the patch proposed by alfonsoml and uncommented the GetXHML line, the patch works perfectly.

Thank you for any suggestions.

[undeadAmnos]

Hello,

I am trying to create a simple character counting functionality into my script and I am still getting this bug in several instances.

System Info:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

AND

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)

FCKEditor Info:
FCKEditor 2.4.3 (downloaded 11/12/07)

Simplified Counting Script:

function FCKeditor_OnComplete(editorInstance){
    editorInstance.EditorDocument.body.fckName = editorInstance.Name;
    if(editorInstance.EditorDocument.addEventListener){
        editorInstance.EditorDocument.addEventListener("keyup", keyUpFunc, true);
    }else{
        editorInstance.EditorDocument.body.onkeyup = keyUpFunc;
    }
}
function keyUpFunc(){
    var bod = this.innerHTML == undefined ? this.body : this;
    var oEd = FCKeditorAPI.GetInstance(bod.fckName);
    var txt = oEd.GetXHTML();
}

The first occurrence:
Occurs in both IE and Firefox

• Load the editor with a value that does not include markup.
  
• Each keystroke then puts the characters in a separate 'p' tag.
  

To temporarily fix this I have started putting 'p' tags around the loading value of the editor.

The second occurrence:
Occurs in Firefox

• Load the editor with a value that includes markup (as mentioned above).
  
• Delete exactly all the text in the editor with the backspace or delete key, then push either button one more time. (Also applies when 'Ctrl+A' then Backspace/Delete is pressed.
  
• Every keystroke then puts each character in a separate 'p' tag
  

As with other cases concerning this bug when I comment out the 'GetXHTML()' call everything works fine.

Any help would be appreciated.

[undeadAmnos]

Replying to undeadAmnos:

I have found that setting the fckconfig value of 'EnterMode' to 'br' will avoid this problem.