[jira] Closed: (WICKET-2948) Clash between AutoComplete request and Form submit request

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

     [ 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.