We are migrating CKEditor issue tracking to GitHub. Please, use GitHub to report any new issues.

The former tracking system (this website) will still be available in the read-only mode. All issues reported in the past will still be available publicly and can be referenced.

Important: we decided not to transfer all the tickets to GitHub, as many of them are not reproducible anymore or simply no longer requested by the community. If the issue you are interested in, can be still reproduced in the latest version of CKEditor, feel free to report it again on GitHub. At the same time please note that issues reported on this website are still taken into consideration when picking up candidates for next milestones.

CKEditor injects special character in Chrome

Under a special circumstance I'm seeing that Chrome is injecting a special character (&#8203;) 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:

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.

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:

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

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:

The ZWS character is totally valid inside the editor.

The ZWS character should never appear in the data and that issue (the original one) was fixed.

There were other issues related to the usage of the ZWS character, but all mentioned here where fixed in 4.4.6.

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()

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.

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?

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: