(Draft)
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.
Contents
DOM Abstraction
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)
The most relevant leak patterns are related to cross references set between DOM objects and JavaScript objects. There are several ways to achieve it, but the result is that you end up with a JavaScript object that has a property pointing to a DOM element that has a property pointing back to the same JavaScript object (even indirectly).
The solution implemented by the DOM Abstraction classes is that we have references in one direction only: JavaScript objects that point to DOM elements. The opposite will never happen.
Expandos Handling
To avoid having references to JavaScript objects inside DOM objects, we should avoid setting the so called expando properties, thus JavaScript properties not native to the DOM.
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.
Garbage collection
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.