Web browser applications are quite sensible to memory leak. Actually, there is a set of well known coding patterns that cause leak. V3 will provide several features to avoid matching such patterns.
Our API provides a DOM abstraction set of classes to manage DOM objects. Memory leak free is the most important benefit of it.
It means that we are able to use the API in any situation, including within well known leakage patterns, and we'll be sure that no leak will happen. The DOM abstraction classes will be the only point of the code dealing with DOM elements, so we can concentrate all our leak free efforts in this set of classes only.
No Cross References (DOM x JS)
But, at the same time, expandos are quite useful, as they can be used to append further information, or back references in the DOM element itself, so those properties can be used later in the code execution.
To have the expandos flexibility, avoiding leakage, we'll provide a specific function to set and get expando properties. Internally, this function will simply set an integer key in a single expando property in the DOM object. That key can be used to retrieve an item from an internal array, which contains all expandos set to that DOM object. So, in the DOM object, we'll have this one and only expando containing an integer value, which doesn’t happen to cause leaks.
Besides those techniques to avoid the common patterns for memory leaks there are other possible problems. For example, using the editor in an AJAX way means creating and destroying instances without reloading the page, and as long as we keep a reference to some object or function in a 'global' object it can't be cleared by the browser.
One example of such pattern is the CKEDITOR.tools.addFunction function: it takes as the parameter a function and it will store it in a private array, including the scope. If we don't remove that reference with CKEDITOR.tools.removeFunction after it's no longer needed, for example using the 'destroy' event of the editor instance, that function and its scope (including variables in a closure) will remain in memory forever because the browser can't call its garbage collector on it.
We must be careful also about adding listeners to the CKEDITOR object because that object will remain live all the time along the page, so the plugins shouldn't add listeners using the initialization methods (beforeInit, init and afterInit) but just at the main scope so it runs only once when the file is loaded. If we have to add a listener inside the plugin code then we must remove that listener when the editor instance is destroyed.
The last pattern is using event listeners or using setCustomData to DOM objects, in those cases we must call clearCustomData() on that object if we want to avoid any leaks.
The ticket 4555 includes some extra info about how to check for increased usage of memory and the patch to clear the known issues related to creating/destroying an editor in a loop.