Tapestry
  1. Tapestry
  2. TAPESTRY-1775

Multiple submit buttons inside async form can invoke incorrect listener

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1.3
    • Fix Version/s: 4.1.5
    • Component/s: Framework, JavaScript
    • Labels:
      None

      Description

      ... this can happen when the updateComponents of the buttons doesnt cover the form.

      So, in such a case, when button1 is clicked it sets itself as tapestry.forms.form['Form'].clickedButton
      and correctly does the async form submit.
      However, the xhr response does NOT include any calls to tapestry.form.registerForm since (as stated)
      updateComponents may not really include the whole form. So, what this means is that the old value for
      tapestry.forms.form['Form'].clickedButton remains - triggering the associated listener no matter how the
      new form is submitted.

      1. form.js.diff
        2 kB
        Francesco Degrassi

        Activity

        Hide
        Andreas Andreou added a comment -

        Francesco, I'm not sure if the case you commented is 100% the same as that of this issue.

        The fix should probably handle it, but if you still have issues, reopen + attach something like
        https://svn.apache.org/repos/asf/tapestry/tapestry4/trunk/tapestry-framework/src/test-data/app1/
        https://svn.apache.org/repos/asf/tapestry/tapestry4/trunk/tapestry-framework/src/test/org/apache/tapestry/integration/app1/pages/

        Thx.

        Show
        Andreas Andreou added a comment - Francesco, I'm not sure if the case you commented is 100% the same as that of this issue. The fix should probably handle it, but if you still have issues, reopen + attach something like https://svn.apache.org/repos/asf/tapestry/tapestry4/trunk/tapestry-framework/src/test-data/app1/ https://svn.apache.org/repos/asf/tapestry/tapestry4/trunk/tapestry-framework/src/test/org/apache/tapestry/integration/app1/pages/ Thx.
        Hide
        Andreas Andreou added a comment -

        Something like your patch was my original thought at well (btw, why are
        you using try catch? just to handle all those return statements? )

        But I have the feeling we'll need to re-register the form and investigate more... perhaps
        additional hidden issues are left un-investigated if we just clear that value

        Show
        Andreas Andreou added a comment - Something like your patch was my original thought at well (btw, why are you using try catch? just to handle all those return statements? ) But I have the feeling we'll need to re-register the form and investigate more... perhaps additional hidden issues are left un-investigated if we just clear that value
        Hide
        Francesco Degrassi added a comment -

        I had the same issue in the following scenario:

        • form not updated asynchronously
        • asynchronous direct link in the form that submits it and calls listener X
        • synchronous search button in the form that calls listener Y

        The problem was the following:

        • clicked on the async direct link -> listener X called
        • clicked on the sync button -> both listeners X and Y called

        Using FireBug shows that the form submitName field was left set to "direct link name" after async submit and following sync submit sent again the "stale" submitName value.

        I attached a patch that clears the subminName hidden field when appropriate after a form submit

        Show
        Francesco Degrassi added a comment - I had the same issue in the following scenario: form not updated asynchronously asynchronous direct link in the form that submits it and calls listener X synchronous search button in the form that calls listener Y The problem was the following: clicked on the async direct link -> listener X called clicked on the sync button -> both listeners X and Y called Using FireBug shows that the form submitName field was left set to "direct link name" after async submit and following sync submit sent again the "stale" submitName value. I attached a patch that clears the subminName hidden field when appropriate after a form submit

          People

          • Assignee:
            Andreas Andreou
            Reporter:
            Andreas Andreou
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development