[
https://issues.apache.org/jira/browse/WICKET-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz resolved WICKET-745.
---------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.3.0-beta4)
1.3.0-rc2
fixed.
instead of not rendering the head if the current request is an ajax request (
if (!stopped && request.isAjax() == false) ),
the AbstractAjaxTimerBehavior now stores whether the head has already been
rendered (ajax or normal request don't matter) or not
in private boolean headRendered, like this:
private boolean headRendered = false;
// in renderHead
if (!stopped && !headRendered)
{
headRendered = true;
response.renderOnLoadJavascript(getJsTimeoutCall(updateInterval));
}
i also updated the unit test to reflect this change
> AbstractAjaxTimerBehavior triggered more than expected after a new Ajax
> rendering
> ---------------------------------------------------------------------------------
>
> Key: WICKET-745
> URL: https://issues.apache.org/jira/browse/WICKET-745
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.0-beta2
> Reporter: Xavier Hanin
> Assignee: Matej Knopp
> Fix For: 1.3.0-rc2
>
>
> When an AbstractAjaxTimerBehavior is rendered in an AjaxResponse due to
> another Ajax callback than the one triggered by the timer itself, it sends a
> new setTimeout javascript call to the client, causing the client to call the
> timer more frequently than expected: x+1 times as expected, where x is the
> number of times the behavior is rendered in a separate Ajax response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
