CKEditor injects special character in Chrome

[Jared Cobb]

Under a special circumstance I'm seeing that Chrome is injecting a special character (​) which is a zero width space character. I stumbled upon this while playing with the editor in our production app. But I created a jsfiddle that replicates the issue with instructions on how to reproduce in the jsfiddle example:

​http://jsfiddle.net/J669P/1/

---

Edit:

1. I just go to ​http://ckeditor.com/demo
2. delete all contents
3. then type some characters
4. press Shift+Enter (or Enter in enter mode BR)
5. and type some more characters.

Don't press Backspace or Delete when you type as this will remove ZWS. To check ZWS I use Chrome dev tools / elements tab. It is important to use Chrome because ZWS is only created when CKEDITOR.env.webkit is TRUE.

[Piotrek Koszuliński]

If it's a ZWS character, then most likely we're creating it. It may be Webkit specific, because of some hack targeted for Webkit only.

[Jared Cobb]

I completely forgot to come back and follow up, I apologize. The issue is actually seen once we save the content. I'm using getData() to get the contents, and when it's saved into the database and rendered out we get the special character. In general, I'm doing this:

$('#submit').on('click', function() {
    var editor = CKEDITOR.instances['comment'];
    var content = editor.getData();
    
    // save my stuff via an ajax call
    // now my data has special characters
});

[Gerbus]

For me, this character is inserted (chrome) when an <img> is not contained within a <p>

[Jakub Ś]

Problem can be reproduced in Blink from CKEditor 3.6.5 rev. [7633] which was a fix for rev. [7624].

NOTE: I wasn't able to reproduce this problem in any Safari

[Jakub Ś]

#11545 was marked as duplicate.

[Jakub Ś]

#11545 was marked as duplicate.

[abbuk]

ZWS character itself is not a problem. However editor doesn't work as expected when ZWS is created. For example:

0. start Google Chrome
1. go to ​http://ckeditor.com/demo
2. delete all contents
3. then type some characters
4. press Shift+Enter (or Enter in enter mode BR)
5. and type some more characters
6. press Ctrl+A (to select all)
7. press Delete

RESULT: only part of text is deleted.

I'm not sure but this can be related to custom-data being set to element where ZWS is created. If I prevent setting custom-data then problems related to ZWS disappear.

[Rob]

abbuk -- can you elaborate on "If I prevent setting custom-data" please? How do you do this?

[Rob]

Replying to abbuk:

ZWS character itself is not a problem. However editor doesn't work as expected when ZWS is created. For example:

0. start Google Chrome
1. go to ​http://ckeditor.com/demo
2. delete all contents
3. then type some characters
4. press Shift+Enter (or Enter in enter mode BR)
5. and type some more characters
6. press Ctrl+A (to select all)
7. press Delete

RESULT: only part of text is deleted.

I'm not sure but this can be related to custom-data being set to element where ZWS is created. If I prevent setting custom-data then problems related to ZWS disappear.

Can you elaborate on what you mean by "prevent setting custom-data" please?

[Piotrek Koszuliński]

Please don't change version. This is an information for us when this issue was introduced.

[abbuk]

Replying to jose:

Can you elaborate on what you mean by "prevent setting custom-data" please?

In this code: ​http://docs.ckeditor.com/source/selection.html Find the following line: element.setCustomData( 'cke-fillingChar', fillingChar ); This code sets a mark that helps ckeditor to find and delete ZWS char when a user types keys like backspace, delete and others. It seems that when a user deletes text by pressing Delete key, editor finds all cke-fillingChar instances and changes them - removes custom data and ZWS. This action happens before actual delete and changes selection/rage or may be DOM. After that ckeditor cannot properly delete text.

If you prevent ckeditor from setting custom-data this will fix the issue with selection, however this will create other problems. At the moment I just prevent ckeditor from deleting ZWS and custom-data (and remove them manually during save).

[Piotrek Koszuliński]

Existence of the ZWS filler inside the editor is not a bug (but its existence in the data is). This is a fix for a very ugly Blink's and Webkit's issues with selections in specific locations - for example inside empty inline elements or between inline elements. We create this character to make selection stick to it.

This is and ugly hack, because the bug is ugly. Unfortunately, this means that there were and perhaps still are issues. However, we managed to fix many of them recently in #12491 and perhaps in #12621 too (both 4.4.6). For instance, the issue mentioned in comment:12 is now fixed. The originally reported TC is also fixed (see ​http://jsfiddle.net/J669P/6/).

To sum up:

1. The ZWS character is totally valid inside the editor.
2. The ZWS character should never appear in the data and that issue (the original one) was fixed.
3. There were other issues related to the usage of the ZWS character, but all mentioned here where fixed in 4.4.6.

[Vern Jensen]

This issue still exists: using editor.document.getBody().getHtml();

I get the ZWS character (E2 80 8B) in the body as a result of shift-returns. See:

​http://dev.ckeditor.com/ticket/14846#comment:1

[Jakub Ś]

Please see ​http://dev.ckeditor.com/ticket/14846#comment:5.

In general CKEditor inserts many helper attributes classes and tags when in wysiwyg mode. When you get HTMl you get all that but when you get data you clean all CKEditor internal helper so you should always use getData()

[OrganicPanda]

I understand the difference between getHtml() and getData() but we are using inline mode and our users are editing parts of the HTML directly (like ​http://ckeditor.com/demo#inline) so what is the solution in this scenario? I can remove all of the ZWS characters at the end but I'm worried I will miss other hacks that CK is using.

[Piotrek Koszuliński]

It's exactly the same – use editor.getData(). If you don't create the editor using CKEDITOR.inline() (which returns the editor instance), then check CKEDITOR.instances.

[OrganicPanda]

Thank you for such a fast reply!

In my case it is a bit more complicated because CK is initialised on on a partial section of the HTML, it does not own the entire document so it's non-trivial to do this (CK instances are created/destroyed as needed dynamically). I realise this is our problem but I was wondering if there was a way to use CK's internal 'cleaning' tools on the whole HTML afterwards?

[Piotrek Koszuliński]

Not in a reliable way unfortunately. Most of the things should be cleaned up by the data processor (editor.dataProcessor.toData()). 7ZWS you can clean manually (we used 7 exactly for this reason... because there were some ridiculous cases where we needed to be sure that these aren't real ZWSes) because DP may not catch them in this case. But there may be more... e.g. if your editors have different configurations, then for cleanup you'd need to use one which has all the features.

THB, I don't understand in what situation it's not possible to use getData() immediately when destroying editor and replacing what was left after editor destruction with the editor data. If you destroy them, then it should be a small change:

var data = editor.getData();
editor.destroy();
elementWhichEditorOccupied.innerHTML = data;

[OrganicPanda]

I certainly should do that but the way this was written in my codebase makes it a bit tricky.

Thank you for your help!