Safari Jquery Ajax Destroy and Replace Bug

[Mark Jenkinson]

A Jquery ajax call grabs a textarea and it's contents. After the new HTML has been inserted into the DOM, the following JS is run to initialize the CKeditor:

CODE: SELECT ALL
if(CKEDITOR.instances['wysiwygeditor']) {
   CKEDITOR.instances['wysiwygeditor'].destroy(true);
}
CKEDITOR.replace( 'wysiwygeditor');

On IE8, IE9, FireFox everything works fine. But in Safari it only works the first time. The second time the Jquery Ajax call is made, the CKeditor WYSIWYG area is blank. If you click the "Source" button, you see that the new HTML source, confirming that the new textarea has been properly been associated with CKEditor, but for some reason, the WYSIWYG area is not properly refreshing. If you click the "Source" button a second time, the WYSIWYG area is now properly displaying the expected content. The challenge is, to my clients, it appears as though the CKEditor is not working, this second time around.

I noticed that on this second attempt, Safari reports "One error in opening the page. For more information, choose Window >Activty"

Looking at "Window>Activity" I see that ​http://mywebsite.com/ckeditor/contents.css fails to load, and reports "cancelled". I'm assuming this is why the CKEditor is failing to display the content properly. At any level, it appears the CKEditor is failing on Safari.

This has been tested on 3.6.1 and 3.6.2, and the results are the same. Any thoughts? Thanks kindly. I'm more than willing to trouble shoot if this helps CKeditor compatibility on Safari.

[Jakub Ś]

You think you might attach the whole page as a TC for this bug?

[Jakub Ś]

Does this issue work on Chrome or both Webkit browsers are affected? If so could you tell me what error do you see in Chrome browser?

Also would it be possible to attach a simple test case file helping to reproduce the problem?

Perhaps this has something to do with CKEditor instance not being completely destroyed? If that's the case than perhaps destroying editor like presented below might help? var e= CKEDITOR.instances['wysiwygeditor']; e.destroy(true); e= null;

[David Syers]

I too was having this issue and it was affecting all webkit browsers. Below is a copy of my post on the forums:

---

I have managed to find a workaround for this that I have tested as working in IE, FF, Safari and Chrome.

The workaround is to wrap the replace statement in a setTimeout command with a 0 second delay - this fixes the issue with webkit browsers of the WYSIWIG side not loading, but can cause a very slight delay.

Below is a copy of my editor function, as I generate my areas in PHP and load with Ajax:

	public function editor($name, $value = "", $config = array(), $events = array())
	{
		$attr = "";
		foreach ($this->textareaAttributes as $key => $val) {
			$attr.= " " . $key . '="' . str_replace('"', '"', $val) . '"';
		}
		$out = "<textarea name=\"" . $name . "\"" . $attr . ">" . htmlspecialchars($value) . "</textarea>\n";
		if (!$this->initialized) {
			$out .= $this->init();
		}

		$_config = $this->configSettings($config, $events);

		$txtHash = md5(time() . rand(0,1000));
		
		$js = $this->returnGlobalEvents();
		$js .= "if (!CKEDITOR.dws".$txtHash.") {";
		$js .= "CKEDITOR.dws".$txtHash."=true;";
		$js .= "if (CKEDITOR.instances['".$name."']) { try{ CKEDITOR.instances['".$name."'].destroy(true); delete CKEDITOR.instances['".$name."']; } catch(e) {}; }";
		if (!empty($_config))
			$js .= "setTimeout('CKEDITOR.replace(\"".$name."\", ".$this->jsEncode($_config).");',0);";
		else
			$js .= "setTimeout('CKEDITOR.replace(\"".$name."\");',0);";
		$js .= "setTimeout(\"delete CKEDITOR.dws".$txtHash.";\",2000);";
		$js .= "}";

		$out .= $this->script($js);

		if (!$this->returnOutput) {
			print $out;
			$out = "";
		}

		return $out;
	}

If you are wondering why my function also has

$js .= "if (!CKEDITOR.dws".$txtHash.") {";

Is because when loading from Ajax some browsers need the scripts running, and others do it automatically, this just prevents the code from being run twice.

[Jakub Ś]

I was not able to reproduce the issue.

I have prepared a sample file which inserts textarea into DOM and then invokes CKEditor. Neither creating one instance after another (create button pressed only) nor first destroying then creating has resulted in error you were talking about (tested with cache disabled).

@dsyers from what you have written it seems that either CKEditor instance gets created before destroy function finishes or that some resources are loaded to long and CKEditor fails to load. Anyway none of this happened I have also checked it on remote server.

@dsyers and @togglemedia could you have a look at my sample file and tell me if I have missed anything there?

NOTE that I haven't implemented insertion of textarea with AJAX as I haven't seen this as something crucial. If loading textarea takes long one should implement CKEditor creation in callback function. Was this perhaps the cause of the problem you were having?

[Mark Jenkinson]

Thanks J. Your test case helped me isolate the issue. As it turns out the issue wasn't the Ajax loading at all. The ajax data was being pushed to a modal dialogue where the CKeditor was, and that would fade in. For some reason, the CKeditor would initialize fine on the first try, but on subsequent calls, the CKeditor would not properly refresh. It only manifested itself on Safari. And because things worked the first time, it wasn't clear why the second would fail...since they were using the same ajax code. At any rate, the solution was to change the order of events, so that the Ckeditor is created AFTER the modal dialogue is visible. It's bizarre that the CKeditor would properly initialize BEFORE the modal is visible on the first try, but on the second try, it would not properly initialize. At any rate, took a while to figure it out, but thanks to everyone here for the help. Case closed on my end.

[Jakub Ś]

Thank you the feedback.

I don't think this is the solution as in your case data was not refreshed but some users had also problems with modal dialog and jQuery.
In their case changing z-index value helped. Please see - ​http://dev.ckeditor.com/ticket/8443 (Perhaps it will be useful in the future:)).

Another z-index and jQuery problem that might be useful in the future was reported here: ​http://dev.ckeditor.com/ticket/5779.

Closing the issue.