You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 29, 2022. It is now read-only.
If destroy() is called then the reset() method is not necessarily called (depending on the configuration) at the correct time, and is sometimes never called. This leaves all memory initialized by plugins potentially in a state in which the GC can not collect. See test case. The destroy() method also does not necessarily clean up all DOM elements and event registrations (for example if buttons are used or the onblur is ignored).
There is at least a few different use cases where this can be observed:
Use a jeditable control that is sensitized by focus. The reset() method may be called if focus is lost, but it may be called after destroy has internally cleaned up the plugin's DOM elements. Either way the reset() call back is due to focus being lost which is subject to how events are dispersed by the browser/JS and not because jeditable is coordinating plugin cleanup (div with id=test2 in test case).
Use a jeditable control with buttons (OK and Cancel) to sensitize the control. In this case the reset() method is never called and the destroy() method does not clean up the buttons or other controls it created (div with id=test in test case).
There are a few options to resolve the issue:
Ensure the reset() method is called before destory() cleans up internal allocations and DOM elements. This way plugins have a hook to clean up. This hook is also already a logical place for destruction to take place without destroy() being called.
Add a destroy() hook that the plugins can override. This may require plugins to use reset() and destroy() methods as two different events which trigger cleanup and would require plugins to add a new method.
Either resolution that is taken it seems like the destroy() method is currently not fully cleaning up all of its DOM elements and associated event listeners.
The text was updated successfully, but these errors were encountered:
Scottmitch
changed the title
Destroy not fully cleaning up and delegating event to plugins
Destroy not fully cleaning up and not delegating event to plugins
May 20, 2014
If
destroy()
is called then thereset()
method is not necessarily called (depending on the configuration) at the correct time, and is sometimes never called. This leaves all memory initialized by plugins potentially in a state in which the GC can not collect. See test case. Thedestroy()
method also does not necessarily clean up all DOM elements and event registrations (for example if buttons are used or theonblur
is ignored).There is at least a few different use cases where this can be observed:
reset()
method may be called if focus is lost, but it may be called after destroy has internally cleaned up the plugin's DOM elements. Either way thereset()
call back is due to focus being lost which is subject to how events are dispersed by the browser/JS and not because jeditable is coordinating plugin cleanup (div
withid=test2
in test case).OK
andCancel
) to sensitize the control. In this case thereset()
method is never called and thedestroy()
method does not clean up the buttons or other controls it created (div
withid=test
in test case).There are a few options to resolve the issue:
reset()
method is called beforedestory()
cleans up internal allocations and DOM elements. This way plugins have a hook to clean up. This hook is also already a logical place for destruction to take place withoutdestroy()
being called.destroy()
hook that the plugins can override. This may require plugins to usereset()
anddestroy()
methods as two different events which trigger cleanup and would require plugins to add a new method.Either resolution that is taken it seems like the
destroy()
method is currently not fully cleaning up all of its DOM elements and associated event listeners.The text was updated successfully, but these errors were encountered: