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 and comment:11 for more details.

[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.

[Jakub Ś]

#10927 was marked as duplicate.

[Jakub Ś]

#11195 was marked as duplicate.

[Piotrek Koszuliński]

#11208 was marked as duplicate.

[Kevin Kamel]

This problem can only occur with jQuery UI 1.10.x or above. If you roll back to version 1.9.x you likely will see the problem disappear. If you still see the issue, assigning a base z-index to CKEditor of some high value will almost definitely fix the problem for you.

Moving forward for jQuery UI 1.10.x there are some substantial problems for CKEditor with the way the z-index stacking works. These problems basically are:

1. iframe based drop downs lose their contents upon reselection under Firefox/Safari/Chrome
2. iframe based contents "flicker" under all IEs
3. dialog windows generated by CKEditor have input fields which cannot be selected or used

I wrote a solution for 3, and there was an existing good solution for 1 (completely unrelated to the suggestion within #6, which seems silly) but I cannot find a way of resolving 2.

For my own application I will likely roll back to 1.9.x, as I have a few weeks into researching and trying to solve them myself, but I'm at a bit of an impasse.

My progress thus far to getting CKEditor working within jQueryUI 1.10.x can be seen on this jqueryUI ticket: ​http://bugs.jqueryui.com/ticket/9087#comment:30

[Piotrek Koszuliński]

Thanks for the details. We'll try to find some time soon to investigate those issues. However, seeing the list of probles, I'm a little bit afraid of what we'll find under jQUI's hood.

[Jakub Ś]

Since Twitter Bootstrap is using jQuery I believe #9934 might be possible duplicate and fix for this one will also fix #9934.

[Jakub Ś]

#11577 was marked as duplicate.

[Jakub Ś]

Solution from ​http://dev.ckeditor.com/ticket/10269#comment:14 which leads to ​http://bugs.jqueryui.com/ticket/9087#comment:30 fixes also #10892.

[Kevin Kamel]

Hi,

Quick update. ​http://bugs.jqueryui.com/ticket/9087 has a continued dialog regarding this bug report. The patches required for 1.10.2 are now somewhat simplified for jQuery 1.11.4, but it does appear that the _allowInteraction issue persists.

[Piotrek Koszuliński]

I've made some research in January this year and this is what I wrote down – ​https://gist.github.com/Reinmar/b9df3f30a05786511a42. There are few more details than in the jQ UI's ticket, but it's the same code basically.

[Kevin Kamel]

Replying to Reinmar:

I've made some research in January this year and this is what I wrote down – ​https://gist.github.com/Reinmar/b9df3f30a05786511a42. There are few more details than in the jQ UI's ticket, but it's the same code basically.

Yes, thanks for that post, I know there was a lot of confusion on this issue. As you note I'm the author for that fix.

After and including version 1.10.3 it appears one of the two issues is corrected. You can see my notes within the same jquery UI ticket (9087). The fix is now a bit simpler moving forward.

[Piotrek Koszuliński]

Ah, I didn't notice :) Thanks for the investigation and patch. That post of mine are meant to end up on ​http://docs.ckeditor.com, but we didn't have time to finish it.

As you may notice in the code sample in my post, I commented out the part with "moveToTop" and left it there as an info for devs using older jQ UI (which I hope they don't :D).