Ticket #325 (closed Bug: wontfix)

Opened 8 years ago

Last modified 2 years ago

API: GetXHTML() temporarily distorts rendering

Reported by: dustball Owned by:
Priority: Normal Milestone:
Component: General Version: FCKeditor 2.4.2
Keywords: Cc:

Description (last modified by alfonsoml) (diff)

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

Attachments

fix empty p.patch (682 bytes) - added by alfonsoml 8 years ago.
proposed patch

Change History

comment:1 Changed 8 years ago by dustball

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

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

comment:2 Changed 8 years ago by alfonsoml

  • Keywords Confirmed added; API removed
  • Description modified (diff)

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.

comment:3 Changed 8 years ago by 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

Changed 8 years ago by alfonsoml

proposed patch

comment:4 Changed 8 years ago by dustball

The proposed patch seems to work well.

comment:5 Changed 8 years ago by alfonsoml

  • Status changed from new to closed
  • Resolution set to fixed

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

comment:6 Changed 8 years ago by fredck

  • Status changed from closed to reopened
  • Version set to FCKeditor 2.4.2
  • Resolution fixed deleted
  • Milestone set to FCKeditor 2.5

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.

comment:7 Changed 8 years ago by fredck

  • Status changed from reopened to closed
  • Resolution set to fixed

Fixed with [256].

Click here for more info about our SVN system.

comment:8 Changed 8 years ago by fredck

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

comment:9 Changed 8 years ago by dustball

Thanks, [256] works well.

comment:10 Changed 8 years ago by fredck

  • Milestone changed from FCKeditor 2.5 to FCKeditor 2.4.3

comment:11 Changed 7 years ago by ychaouche

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:12 Changed 7 years ago by fredck

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:13 follow-up: ↓ 14 Changed 7 years ago by undeadAmnos

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:14 in reply to: ↑ 13 Changed 7 years ago by undeadAmnos

Replying to undeadAmnos:

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

comment:15 Changed 2 years ago by j.swiderski

  • Keywords Firefox Confirmed removed
  • Status changed from reopened to closed
  • Resolution set to wontfix

FCKeditor was retired and is no longer supported. All active development was moved to its successor, CKEditor 3.x, that is a fully mature and far superior product. We recommend you upgrade as soon as possible since this issue is no longer a problem in current code base.

AutoSave for CKEditor can be found on our Add-ons forum: http://cksource.com/forums/viewtopic.php?f=18&t=24128

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy