CKEditor's editor area is not editable in IE8/IE7 and no data is displayed in Firefox

[Senthil]

To reproduce this issue in IE8/7, please open the attached sample file in IE8/7.

1. Click the "Click me for multiple times to see the issue" button and you will get an alert as 'instance ready' and press ok. Now you will see the editor's default data.
   

2. Repeat the step no.1 again, now click on the editor's content 'Do you see the problem..!!!' but you can't edit/change the content for atleast 2 minutes.
   

If you don't see the problem, please repeat the steps 1 & 2 again.

To reproduce this issue in Firefox 3.x, please open the attached sample file in FF3.x.

1. Click the "Click me for multiple times to see the issue" button, now you will not see any data inside the editor's area. Now click on the source control, you will get the alert 'instance ready' and then you will see the data in source mode.

This is a show stopper since the editor is not editable in IE and no data is displayed in FF.

[Martin Kou]

Retracted review request - the problem with IE7/8 is still there.

[Martin Kou]

Just did some more tests - turns out IE7 has cached the non-patched code. After deleting all caches and restarted IE7, I'm not having the bug again.

[Martin Kou]

#3523 marked as dup to this ticket.

[Martin Kou]

Retracting review request - I'll wait for #3827 to get committed first and add the CHANGES.html entry in the next patch.

[Martin Kou]

Retracted review request - the new loading method never works in Safari.

[Martin Kou]

Updated patch to make it work under Safari and Opera.

[Martin Kou]

After seeing some test cases from Oracle - the problem is still not fixed in IE7 or IE8. The delay before the editing area becomes editable is still occurring randomly.

[Garry Yao]

Sorry, didn't get the last comment by Martin, in which case does it fails? It works fine for me in IE7.

[Martin Kou]

Try Oracle's test case with the new patch on IE7 or IE8 - you'll see that sometimes after pressing the button you will not be able to put focus to inside the editor.

The bug is random is it's definitely a browser bug (and a very nasty one at that). After the button is pressed, the browser's selection model is somehow broken - not only is the things inside the editing area not selectable, everything in the browser window is also not selectable. If you try to click outside of the editing area once and click the editing area again, the caret will come back.

I'm still trying to find a fix for it at the moment.

[Martin Kou]

The bug in IE7 is found to be caused by the innerHTML assignment in Oracle's sample. Alternatively, it can also be triggered by calling destroy().

I've posted an updated sample where you can reliably reproduce the big in IE7 or 8:

1. Put replacebycode.2.html in the _samples folder of trunk.
2. Open it in IE, select some words in the editing area.
3. Click the button once.
4. Now you can't select anything in the browser window.

[Martin Kou]

The culprit of the IE7 or 8 bug is the removal of the editing area - this is done by the innerHTML assignment in Senthil's sample, or, it can be done with destroy() that's within our API.

Senthil's sample is actually doing one thing wrong - he should have called destroy() before creating another editor instance of the same name. This causes the JavaScript error in IE and is not our fault. However, for safety, I've added a check in the editor constructor to check for duplicated instances.

So now the only problem left for us is breaking IE7/8's selection system with destroy() - which is within the scope of our API. The fix to this, is to put the selection back to the parent document without scrolling the window.

[Garry Yao]

Hum...the editor document loading seems much stable now.

[Martin Kou]

Fixed with [3794].

Click here for more info about our SVN system.