Javascript error in Firefox: FCK is not defined

[gboissiere]

Dynamically adding and removing FCKEditor textareas is creating Javascript errors. I created a test page for this issue, using the latest nightly build:

​http://www.boissiere.com/fckeditor/test_fckeditor.php

To reproduce the problem:

• go to the URL above
• click on 'Add Response' --> a new FCKEditor textarea dynamically appears
• delete the FCKEditor textarea you just created by clicking on the "Delete" link
• click on 'Add Response' again

-----> ERROR: FCK is not defined

[Pete Hurst]

I'm seeing this bug while trying to fix #234. My comments there contain some further observations. Basically:

• In fckeditorapi.js line 143, in _AttachFormSubmitToAPI(), a 'submit' event is attached to the parent form, calling FCK.UpdateLinkedField
• This event is not DEtached when an FCK is removed from the DOM
• Then, when a submit event fires (which in #234 is happening in a screwy place when the editor has been briefly removed between postbacks), the function is called, but no longer has a base object. Any attempt to access the FCK variable fires the error. I've tried adding if (FCK) { ... } and if (FCK==undefined) { ... } but the error is still thrown. This could even indicate a bug in Firefox itself.

So; I need a way to detach this event when the FCK is removed from the page. Unfortunately I can't figure out how to access the FCKTools object to use its RemoveEventListener method, to detach the event from the parent form. The _AttachFormSubmitToAPI() function seems to be called from fckeditor.html, inside the iframe itself; but I need to call a function from *outside* the iframe to detach it.

I've tried using the onunload event in fckeditor.html, but by that point the GetParentForm() function returns null, so there is no way to detach the event there.

Can we escalate this - these events really should be getting cleaned up to avoid memory leaks and so forth!

[Pete Hurst]

Additionally, I noticed there WAS a reference to 'this' (in the UpdateLinkedField function); but at the time the error fires, 'this' is a reference to the parent form. When called elsewhere, it's a reference to the FCK object.

[Pete Hurst]

gboissiere: I can't reproduce the error no your test page! Have you changed anything and/or fixed the issue?

For anyone wanting to reproduce the bug, I've set up tests for #234, which ultimately leads to #1255 - up now at ​http://fcktest.pixelpunch.co.uk/Test3.aspx. See attachments on #234 for the code.

Instructions: Click 'Post' twice; on the second postback the an error appears. The number of errors produced increases by 1 with each subsequent postback.

[Pete Hurst]

Test page moved to: ​http://fck.randomdev.co.uk

[Pete Hurst]

Note: it's test no.3 at the above link that produces #1255.

I just had another look at gboissiere's test page and it is reproducing the bug. Must have been tired the last time I was looking at it! Still, the circumstances of the two tests are a little different so it's probably useful to have both.

[Pete Hurst]

This can now be worked around. The fix for #234 includes a patch against FCKeditor which adds a "PreventSubmitHandler" config option. By setting this to true, the _AttachFormSubmitToAPI() in fckeditorapi.js will be stopped. This means you will have to provide your own onsubmit event to called the UpdateLinkedField() on all your editors.

The permanent fix for this problem needs investigation of the _AttachFormSubmitToAPI function. The code has existed since rev. 18 (FredCK). There's a Firefox-specific (or at least IE-excluded) block that takes the first event that was (already) attached, swaps it for a new one, and keeps a reference to the old one:

// Attach to the onsubmit event.
		FCKTools.AddEventListener( oForm, 'submit', FCK.UpdateLinkedField ) ;

		// IE sees oForm.submit function as an 'object'.
		if ( !oForm._FCKOriginalSubmit && ( typeof( oForm.submit ) == 'function' || ( !oForm.submit.tagName && !oForm.submit.length ) ) )
		{
			// Save the original submit.
			oForm._FCKOriginalSubmit = oForm.submit ;

			// Create our replacement for the submit.
			oForm.submit = FCKeditorAPI._FormSubmit ;
		}

As you can see, an event listener is added (this is performed in a Firefox-specific way by fck_gecko).

THEN, the submit event (with handlers to FCK attached) is stored in _FCKOriginalSubmit and a new submit handler is introduced: FCKeditorAPI._FormSubmit.

That handler is defined in a eval at the beginning of fckeditorapi.js:

				'_FormSubmit : function()' +
				'{' +
					'for ( var name in FCKeditorAPI.Instances )' +
					'{' +
						'var oEditor = FCKeditorAPI.Instances[ name ] ;' +
						'if ( oEditor.GetParentForm && oEditor.GetParentForm() == this )' +
							'oEditor.UpdateLinkedField() ;' +
					'}' +
					'this._FCKOriginalSubmit() ;' +
				'},' +

So:

• Each FCK's UpdateLinkedField method is attached as an event listener to form.submit
• form.submit is stashed away in _FCKOriginalSubmit
• FCKeditorAPI._FormSubmit replaces the form.submit
• FCKeditorAPI._FormSubmit eventually runs, and first calls UpdateLinkedField on every editor instance that exists
• THEN calls _FCKOriginalSubmit which is itself an UpdateLinkedField!

So, even with just one instance on a page, UpdateLinkedField is actually getting called twice because the events have been nested.

Furthermore, if we introduce additional editor instances, they will attempt to add further event listeners to the form.submit. This time since _FCKOriginalSubmit already exists, the event swapping will not occur - due to the if ( !oForm._FCKOriginalSubmit [...] ). BUT it's possible that 3rd-party Javascript frameworks could be performing their own manipulation of form.submit and even the form object itself ... so at the stage where we are several AJAX updates down the line, and multiple instances of FCKeditor have been created and destroyed, who knows what will be happening... Also since form.submit is no longer the original event, but is now FCKeditorAPI._FormSubmit, I'm not sure if the AddEventListener will still behave as expected.

Now, the FCKeditorAPI._FormSubmit method is probably better, since it's just one handler that needs attaching which will update all instances, as opposed to using AddEventListener to attach an event handler for each and every instance.

The notes on revision 18 mention a SourceForge BUG-1610790: ​https://sourceforge.net/tracker/?func=detail&atid=543653&aid=1610790&group_id=75348

..But I can't view that URL because it's private - so it's not clear exactly what that code's meant to be doing! I think the reason this bug is Firefox-specific is because of the IE 'object' test.

Really, I'm not sure why the additional event manipulation is happening. Is there a reason why the FCKTools.AddEventListener call isn't enough?

[Roman]

I'm getting this exact error when using CFTEXTAREA with richtext=true attribute when the CFFORM is inside a CFDIV. It loads fine on the initial page load, but after I do a submit and the form reloads trough AJAX, then I get this error. Any solution for a fix?

[Pete Hurst]

pixelwiz, see ticket #234 . You will need to set FCKConfig.PreventSubmitHandler = true ; and then provide your own hooks into whatever AJAX system you are using to call the UpdateLinkedField() function on your editor, and also into onsubmit to call it then as well. #234 only fixes this error in the context of ASP.NET which is why #1255 is still not itself resolved. I'm not a Coldfusion developer so I can't help you any further as to how you go about modifying the CFTEXTAREA to acheive what I've described.

Your other option is to move to CKEditor 3.0, however there are NO integrations yet available for that, all the integration must be performed manually in Javascript, including again hooking into your AJAX library to tell CK to updateData() when an AJAX postback occurs. Perhaps you could search the forums for information on CF integration.

[Roman]

The great and horrible thing at the same time about coldfusion is their fancy tags. They make it very easy to make a textarea be an FCKEditor, all I do is set richtext=true in the attributes for the tag. Unfortunately the rest is done by CF. It includes the JS and write functions and what not.

So, I'm not sure where exactly would I put the FCKConfig.PreventSubmitHandler = true ; line?

As for hooking back into AJAX, if I did this through jQuery or similar, that would be cake. Unfortunately trying to go the easy route using CFFORM inside a CFDIV, which automatically submits the form via AJAX, doesn't give me much room to change things as again that JavaScript is generated by CF.

So it looks like I either need to find the part of JS code generated by CF and over-ride something, but I'm not sure what, or go with a whole separate solution?!?

[Pete Hurst]

FCKConfig.PreventSubmitHandler = true can go in your fckconfig.js, wherever that is located.

Beyond that, as I said, I'm not a CF developer, so I can be of no further help. I suggest you search the FCKEditor and Coldfusion forums for advice on how to modify/override their default integration with FCK.

[sandhya]

Hi,

I am

[Jakub Ś]

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.