editor.destry() throw an error

[Charlie]

<button onclick="javascript:CKEDITOR.instances.editor1.destroy();">Click</button>

I add this code in the inline editing demo page.

it throw an error.

bug condition is do not click edit area before destry().

if the edit area once actived, destry action will not throw error. or we put the destry action in window.setTimeout, it will neither throw error.

[Charlie]

I tested version 4.0.1.1, it didn't throw error.

[Piotrek Koszuliński]

It's reproducible on 4.0.2 and 4.1; works fine on 4.0.1.

[Piotrek Koszuliński]

Issue introduced by ​git:b862b5f.

[Piotrek Koszuliński]

Pushed ​t/10219.

[Piotrek Koszuliński]

PS. I forgot to mention TC:

• Open inlineall sample.
• Destroy one of inline editors.
• Click on any of the editors.

On mouseup error is thrown.

[Piotrek Koszuliński]

We found that magicline may unsafely execute few functions on every switch to wysiwyg mode. However, only one of these calls caused issue and it is fixed in this ticket. Since we couldn't find a TCs for the rest, but also we don't want to rewrite part of magicline now, I reported #10227.

[Piotrek Koszuliński]

Fixed on ​git:a7b117f.

[Teresa Monahan]

Replying to Reinmar:

Fixed on ​git:a7b117f.

I can still reproduce this. The error does not occur if I destroy the editor instance through the browser console. However it does occur if I include this button in the inlineall.html sample and click it:

<button onclick="CKEDITOR.instances.editor1.destroy();">Click</button>

The error is: TypeError: sel is null /ckeditor/plugins/clipboard/plugin.js Line 906

[Jakub Ś]

I can confirm this is still happening. Opening page with button and clicking it without activating editor results in error.

[Piotrek Koszuliński]

We missed a case, when mouseup is fired at exactly the same moment when destroy() is called. We were too focused on reproducing this issue from code.

Unfortunately we won't be able to include a patch for the second part of this issue in 4.0.3, because it's too late.

I'm targeting this ticket to 4.1.1.

Note that this error should not cause any problems because it is thrown inside setTimeout() in native event listener.

[Piotrek Koszuliński]

Additional TCs can be find here: #9684 and if not already fixed, should be fixed in this ticket.

[Olek Nowodziński]

Created branch ​t/10219b with a simple solution that cleans remaining deferred callbacks on editor destroy. It seems to solve all the "click&destroy" cases.

[Olek Nowodziński]

Merged into master ​git:86d354eb6f.

[Joe]

I am getting the error outlined here #9684 in 4.1.2 it is causing IE 10 to display an error dialog. Why not check if the selection returned is null before calling a method on it, or alternately have getSelection() not return null? Right now the code is not handling all the possible return values [specifically null] coming from getSelection().

I am using CKEDITOR.inline() to start the editor and <instance>.destroy() to remove the editor. I only wanted to document this, we don't need a fix we'll work around it.

[tepez]

This is not fixed, yet. I had to add an additional check in the timeout that the instance is not yet destroyed.

This happens because the timeout cancellation(on destroy) is triggered after the timeout itself when the instance is destroyed during mouse-down (for me, it happens when an instance is being destroyed during dragging).

If you need, I can create a jsfiddle that shows this error.

editable.attachListener( CKEDITOR.env.ie ? editable : editor.document.getDocumentElement(), 'mouseup', function() {
  mouseupTimeout = setTimeout( function() {
    if (editor.state != 'destroyed') {
      setToolbarStates();
    }
  }, 0 );
});		

[Jakub Ś]

If you need, I can create a jsfiddle that shows this error.

Please do because I wasn't able to reproduce this problem.