[
https://issues.apache.org/jira/browse/WICKET-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898668#action_12898668
]
Michael Brinkman commented on WICKET-2739:
------------------------------------------
Interestingly, I'm seeing this issue manifest as a precondition failure running
Wicket 1.4.9 on IE8, but not on FF3.6.8 (opposite browser compatibility issue).
In the IE JS debugger I tracked it back to the same basic root cause where the
element passed in to 'Wicket.&&' is clearly not the form component the behavior
was added to.
The only thing I'll add to Russell's description of the issue and suggested fix
is that I was able to work around this by altering the precondition script to
be entirely name based, instead of using a reference to a DOM element:
AjaxFormValidatingBehavior behavior = new
AjaxFormValidatingBehavior(myForm, "onblur") {
protected CharSequence getPreconditionScript()
{
return "return Wicket.$$('" +
((FormComponent<?>)getComponent()).getInputName() + "')&&Wicket.$$('" +
getForm().getMarkupId() + "')";
}
};
I'm still pretty new to Wicket though, so I'm not sure if the form validating
behavior is intended to be added to anything other than a FormComponent. If it
is, then obviously this wouldn't be a very desirable fix.
> Throttling breaks AjaxFormSubmitBehavior's precondition check
> -------------------------------------------------------------
>
> Key: WICKET-2739
> URL: https://issues.apache.org/jira/browse/WICKET-2739
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.5
> Environment: wicket 1.4.5, wicket quickstart, windows XP; FireFox
> 3.5.7 used in quickstart test
> Reporter: Russell Morrisey
> Attachments: throttleBreaksPrecondition.zip
>
>
> AjaxFormSubmitBehavior#getPreconditionScript() looks like:
> return "return Wicket.$$(this)&&Wicket.$$('" + getForm().getMarkupId() + "')";
> The javascript keyword 'this' should point to the DOM element which initiated
> the ajax event. (It wants to check that the component still exists on the
> page, before initiating the ajax request, as well as the form this behavior
> is linked to). When using an AjaxThrottlingCallDecorator to throttle the ajax
> request, the throttle callback function is not bound to the DOM element. The
> result is that 'this' refers to the window element, in the context of the
> throttle callback. The precondition function gets bind(this) called on it,
> but it's the wrong 'this'. I think that the throttle callback should be bound
> to 'this' at the time the callback is defined.
> AbstractDefaultAjaxBehavior#throttleScript(...) should be changed from:
> return new AppendingStringBuffer("wicketThrottler.throttle(
> '").append(throttleId)
> .append("', ")
> .append(throttleDelay.getMilliseconds())
> .append(", function() { ")
> .append(script)
> .append("});");
> to:
> return new AppendingStringBuffer("wicketThrottler.throttle(
> '").append(throttleId)
> .append("', ")
> .append(throttleDelay.getMilliseconds())
> .append(", function() { ")
> .append(script)
> .append("}.bind(this));");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
