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.

The patch works well, and I was about to give it R+. In the last minute, I've decided also testing the performance of it by loading a ​log document and checking the output generation performance. It's almost 40% slower after the patch.

We need also some performance optimization at this point. If we want to you CKEDITOR.tools.htmlEncode, we need to rewrite it, much probably avoiding having a function call chain there. Otherwise we can think about optimizing it in the writter functions directly.

Ops, moving back to the 3.2 as this patch is also fixing another important issue: pasting is not working on some cases. For example, it's not possible to past this entire page (all browsers): ​http://www.w3.org/TR/html4/

4719_3.patch breaks test case dt/core/tools::test_htmlEncode2, specifically character quote should not be always escaped, it's only feasible when considering an attribute value context, the php ​htmlspecialchars will be a good API ref for it.

The current implementation of CKEDITOR.tools.htmlEncode is over complicated, it's safely enough to just escape manually five characters there, by a RegExp, without bothering DOM.

4719_3.patch breaks test case dt/core/tools::test_htmlEncode2, specifically character quote should not be always escaped, it's only feasible when considering an attribute value context, the php ​htmlspecialchars will be a good API ref for it.

Well, not a big issue. It may avoid us having a dedicated htmlAttEncode function.

The current implementation of CKEDITOR.tools.htmlEncode is over complicated, it's safely enough to just escape manually five characters there, by a RegExp, without bothering DOM.

The DOM trick is a nice attempt to make it work as fast as possible in all browsers. It's a nice solution, but we may change it so we avoid the functions chain.