Cannot disable auto inline functionality when CKEditor is being loaded via Ajax

[ctrl]

Hello,

It seems it is not possible to disable the auto inline functionality when CKEditor is being loaded via Ajax. This is because DOM is ready on the moment CKEditor executes the following code:

CKEDITOR.domReady( function() {
    !CKEDITOR.disableAutoInline && CKEDITOR.inlineAll();
} );

I cannot set CKEDITOR.disableAutoInline before that, because CKEDITOR does not exist in window yet.

Is there a way to resolve this nasty issue?

[Piotrek Koszuliński]

It depends on what library you use to load scripts asynchronously (that's what you're doing I guess). Libraries usually let you define an onload callback and you can use it to set the flag. A workaround would be to create a script file in which you set the flag's value and loading it right after ckeditor.js.

In any case, this is an issue with the way how you load scripts, not with CKEditor itself.

[ctrl]

No, both of these are wrong. Both the solution with the onload callback and this workaround: "A workaround would be to create a script file in which you set the flag's value and loading it right after ckeditor.js." will not work.

If you read the code of CKEditor, you will see that the event "inline" will fire BEFORE I have chance to set the flag's value. The approach you suggested will work if you load CKEditor code via <script> element and DOM is not ready, but the workaround will not work if DOM is already ready.

Please prove your words with a prototype, or reopen the ticket.

[Piotrek Koszuliński]

First of all, I have not understood your report correctly because it was a bit vague. I thought that you have a problem with executing code after loading ckeditor.js. As I understand it now, you have problem with executing code before ​this condition is executed.

This is more serious problem, I admit. Though, as you can see the callback is executed after a timeout, so if you are able to execute code synchronously after loading ckeditor.js, you'll be able to stop auto inline feature.

I attached inlineall.html in which I showed that script's onload callback is executed synchronously and I was able to stop auto inline feature. Call appendCKEditor() from console to check it. It worked for me on FF and Chrome.

This is only a workaround though, because a script loading library may not call callbacks synchronously. In such case I'm afraid that we can't do much. We could as a last resort call some CKEDITOR_ONLOAD_CALLBACK function if defined, but this is a hack.

Any ideas?

[Piotrek Koszuliński]

I'm setting status to "pending" so we can discuss whether this is a real issue or/and we want to fix it somehow.

[dk]

This is real problem. If we already have some contentEditable tags and want to load CKEditor without attaching to them, we can not do this.

I think the solution can be implemented really in two lines of code in 'ckeditor.js'. How about to add handling a variable:

window.CKEDITOR_DISABLE_AUTO_INLINE = true;

which will turn off any of autoinline functionality. It can be set right before async including CKEditor's script in the doc.

CKEditor already has something about it:

window.CKEDITOR_BASEPATH='/path/';

so this workaround type will not be something new.

---

Also I need to notice that currently there is no way to detach inline editor after adding JS:

incCkeditor(); // async include
CKEDITOR.instances[elementId].destroy(); // Fatal: CKEDITOR is undefined

So the only chances to disable braking elements are: 1) Add new global flag 2) Disable autoinline at all 2) Do autoinline only to elements with class "cke-auto-inline"

[Frederico Caldeira Knabben]

I'm all for CKEDITOR_ONLOAD_CALLBACK (actually CKEDITOR_ONLOAD only). This is a useful feature and it would easily solve all kinds of similar issues, not exclusively this one.

[Piotrek Koszuliński]

I'm all for CKEDITOR_ONLOAD_CALLBACK (actually CKEDITOR_ONLOAD only). This is a useful feature and it would easily solve all kinds of similar issues, not exclusively this one.

Agree. More general option will be better.

I'll try to find a time for this ticket in 4.5.0, but for now no milestone.