Affects Version/s: 1.4.9
Fix Version/s: None
I have posted a mail about this issue to the wicket-users mailing list, but have not received any response. It seems to me that this is a conceptual problem in how Wicket handles requests from Ajax, thus I am opening this bug.
Text of posting:
suppose there is a TextField with an AutoCompleteBehavior in a Form.
Pressing a key will create an Ajax RequestCycle to process the key, and
will finally invoke RequestCycle.detach(), which will invoke
Pressing enter will create a normal RequestCycle to process the form,
which will also invoke RequestCycle.detach(), and then
Now suppose there are other FormComponents in this Form, some taking a
few ms to validate, and suppose the first field generated a FeedbackMessage.
It is obvious that now, there will be two threads running concurrently,
one processing the Ajax RequestCycle (A), and one processing the Form
submit RequestCycle (B).
While the second thread B is still processing the Form, the first thread
A already finished and cleans up the FeedbackMessages - which the second
thread B that added them didn't even have a chance to render yet!
This can be easily provoked if the text field is set as required, by
entering a single character in the empty TextField, pressing Backspace
and immediately Enter to submit the Form. This scenario should be quite
The result is that there are no feedback messages shown to the user, but
in development mode the usual message that a "Component-targetted
feedback message was left unrendered" is logged.
I have worked around this problem by using
in a custom RequestCycle constructor.
If this is indeed as I suspect a bug in Wicket, I will file a bug for it.
It seems to me that it is wrong in any case that a RequestCycle cleans
the FeedbackMessages from another RequestCycle.
In Session, there is documentation referring to "flash messages", which
I suppose is what feedback messages were called previously, and there is
mention that these must persist across RequestCycles under some
circumstances - which seems correct considering the condition in
Thus, direcly associating FeedbackMessages with a RequestCycle is not
possible. But it should at least be possible to note which RequestCycle
generated which FeedbackMessage, and then clean only those
FeedbackMessages owned by the RequestCycle in the normal case, and only
clean these persistent FeedbackMessages where necessary.