Issue with ckeditor 4.0.2 running in a jquery dialog

[jhhawk]

I posted the following in the forums on 3/13/2013:

We've been running ckeditor 3.6.4 in a jquery (1.7.2) dialog for the last year. We recently had to update to jquery version 1.9.1 and jquery ui version 1.10.1. In the process we also upgraded to ckeditor 4.0.2. We're still using frame editing so we wouldn't have to change the existing code.

We're now seeing the following issue with the ckeditor dropdowns:

In FireFox, if you click a dropdown, then click it again to close it, the dropdown remains but the option values are gone. Subsequently, the same dropdown or any other dropdown also open with no options displayed. In Chrome the behavior is virtually the same, just triggers differently - click the dropdown to open, click it to close, then click it again and it exhibits the same behavior. Using FireBug we get the following error: "TypeError: a.contentWindow is null", referencing line 324 in ckeditor.js. (standard version).

We also downloaded the source code (4.02 full version), created our own build, and got a different error:

"TypeError: $.contentWindow is null - return selected.$;"

I'm attaching a file that recreates the issue. It requires ckeditor 4.0.2 standard to be in the same directory to run. The file should also be renamed to 'index.html'.

Please let me know what we're doing wrong, or if this is a legitimate bug. We have a major launch this month and would like to get this resolved as quickly as possible.

Thanks in advance to anyone who helps.

Please have a look at comment:6 for possible solution.

[jhhawk]

sample html file. requires ckeditor 4.0.2 standard to be in same directory to run.

[Jakub Ś]

I was hoping that you are using perhaps old version of jQuery UI and new one has fixed the problem but unfortunately this isn't the case.

It seems that jquery UI 1.10.0 has introduced some change that is causing this all the way down from CKEditor 4.1 to 3.0.
This issue should be reported to jQuery.

---

For quite some time we had an issue where jQuery didn't allow writing in dialogs. This was fixed in jQuery UI 10.0.2 ​http://bugs.jqueryui.com/ticket/9087#comment:14 (Please see also #10081).
Unfortunately because of this issue the fix isn't that relevant. It seems that the only workaround is to use jQuery UI version 1.9.2 (below 1.10.0) and config.baseFloatZIndex = 102000; trick.

[Bryan Whalen]

I encountered this issue as well after doing updates to CKEditor and jQuery UI. I was able to work around it by overriding a bit of the jQuery UI dialog's behavior. Be a bit careful with this as I am able to make some assumptions regarding dialogs being modal. I found the issue was caused by the dialog's built-in efforts to always move it to the top on mouse clicks. I overrode the internal _moveToTop function to only execute normally if no event was provided (indicating it was called directly, probably on initialization), or if it wasn't modal (just to be safe).

$.widget("ui.dialog", $.ui.dialog, {
    _moveToTop: function (event, silent)
    {
        if (!event || !this.options.modal)
        {
            this._super(event, silent);
        }
    }
});

[Jakub Ś]

#10283 was marked as duplicate

[Bryan Whalen]

This is very likely linked to this ticket:

​http://bugs.jqueryui.com/ticket/9166

Looks like the jQuery UI 1.10 changed the dialog sorting stuff to directly move the dialog elements around in the DOM instead of mucking with z-index, causing things to detach. This is probably what breaks the dropdowns.

[Jakub Ś]

#10410 was marked as duplicate.

[Steve Hatchard]

We found that the issue was that whenever you move an iframe in a document it's contents are lost as cited by theses links

​http://bugs.jqueryui.com/ticket/9067

​https://bugs.webkit.org/show_bug.cgi?id=13574

After reviewing this jquery ui forum post

​http://bugs.jqueryui.com/ticket/9166?cversion=0&cnum_hist=14

we took the "hack" by scott gonzalez (comment 11) and changed

if (this.uiDialog.nextAll(":visible").children('iframe').length > 0)

to

if (this.uiDialog.nextAll(":visible").children().find('iframe').length > 0 || this.uiDialog.find('textarea.ckeditor').length > 0)

this ensures all iframes in the dialog AND any within the editor within the dialog do not get moved either.