[ https://issues.apache.org/jira/browse/WICKET-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg closed WICKET-2948. --------------------------------- Assignee: Igor Vaynberg Resolution: Duplicate > Clash between AutoComplete request and Form submit request > ---------------------------------------------------------- > > Key: WICKET-2948 > URL: https://issues.apache.org/jira/browse/WICKET-2948 > Project: Wicket > Issue Type: Bug > Components: wicket > Affects Versions: 1.4.9 > Reporter: Florian Wunderlich > Assignee: Igor Vaynberg > Priority: Minor > > 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. > Original posting: > http://apache-wicket.1842946.n4.nabble.com/Clash-between-AutoComplete-request-and-Form-submit-request-td2282075.html#a2282075 > Text of posting: > Hi, > 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 > WebSession.cleanupFeedbackMessages(). > Pressing enter will create a normal RequestCycle to process the form, > which will also invoke RequestCycle.detach(), and then > WebSession.cleanupFeedbackMessages(). > 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 > common. > 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 > if (request.isAjax()) > setAutomaticallyClearFeedbackMessages(false); > 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 > WebSession.cleanupFeedbackMessages(). > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.