If I instantiate an editor into the following markup:
and then move the "container" node so it appears before the "<p>Blah</p>" node, the editor stops working when using Firefox 3.6.3. Seems to work okay under IE 8 in all modes.
Is this a known issue? Any workarounds?
Thanks.
<p>Blah</p> <div id="container"> <textarea id="editor"></textarea> </div>
and then move the "container" node so it appears before the "<p>Blah</p>" node, the editor stops working when using Firefox 3.6.3. Seems to work okay under IE 8 in all modes.
Is this a known issue? Any workarounds?
Thanks.
Re: Moving CKEditor instances around the DOM
Re: Moving CKEditor instances around the DOM
I use the jQuery UI Dialog component with ckeditor. This component in the current stable version does this in the open-function line 278: if (uiDialog.next().length) uiDialog.appendTo('body');
This brakes ckeditor like discussed here.
My solution is to comment out this line in the source code of jquery.ui.dialog.js as a workaround.
Of course nobody can see this on an official ckeditor demo, because there is no "3rd party component" doing things ckeditor can't deal with. But in productive real life this can happen.
For better compatibility it would be great to have a special "developer-plugin" which pops up javascript alerts with hints on known unsolvable issues if one occurs. For example if ckeditor gets moved on the dom it pop ups and informs the developer about this problem. Then the developer can search on his or 3rd party sourcecode to find where the dom-movement has happened. With a flag in the config file of ckeditor this feature should be turned on/off.
There are more things like the above one. I will try to report about it later. But I can say I recommend creating a textarea with at least <p> </p> as content and init the ckeditor instance by replacing the textarea and do not create an empty div and append ckeditor instance to it. When your project gets bigger this could get a problem for you.