Ernesto Reinaldo Barreiro created WICKET-4975:
-------------------------------------------------
Summary: client side memory leak on date picker
Key: WICKET-4975
URL: https://issues.apache.org/jira/browse/WICKET-4975
Project: Wicket
Issue Type: Bug
Components: wicket-datetime
Affects Versions: 6.4.0, 1.5.8, 1.4.21
Environment: any
Reporter: Ernesto Reinaldo Barreiro
Priority: Minor
Under certain conditions date picker component leaks memory at client side.
More concretely DatePicker#renderHead tries to clean up existing date pickers
via
AjaxRequestTarget target =
component.getRequestCycle().find(AjaxRequestTarget.class);
if (target != null)
{
String escapedComponentMarkupId =
getEscapedComponentMarkupId();
String javascript = "var e = Wicket.$('" +
escapedComponentMarkupId + "Dp" +
"'); if (e != null && typeof(e.parentNode) !=
'undefined' && " +
"typeof(e.parentNode.parentNode !=
'undefined')) {" +
"e.parentNode.parentNode.removeChild(e.parentNode);" + "YAHOO.wicket." +
escapedComponentMarkupId + "DpJs.destroy();
delete YAHOO.wicket." +
escapedComponentMarkupId + "DpJs;}";
target.prependJavaScript(javascript);
}
but this fails if "panel" containing date pickers is completely replaced via
AJAX. E.g. for date pickers placed on an AJAX navigated repeater. The result is
that client side object
YAHOO.wicket
object grows and grows... and for
1- Wicket 1.5.x and wicket 1.4.x this means time for creating new date pickers
grows steadily.
2- For wicket 1.6.x there seems not to have any performance hindrance (only
the memory leak).
I attach quick starts demonstrating this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
