[WICKET-4975] client side memory leak on date picker

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 1.4.21, 1.5.8, 6.4.0
• Fix Version/s: 6.5.0
• Component/s: wicket-datetime
• Environment: any
• Assignee: Martin Tzvetanov Grigorov
• Reporter: Ernesto Reinaldo Barreiro
• Created: 14/Jan/13 18:45
• Updated: 28/Jan/13 15:05
• Resolved: 18/Jan/13 09:06

Description

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.