Uploaded image for project: 'Click'
  1. Click
  2. CLK-333

AutoCompleteTextField cannot be added on form. Form cannot be submited.

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.5 M1, 1.4.1
    • Component/s: core, extras
    • Labels:
      None

      Description

      When one is trying to use AutoCompleteTextField field on a form
      or a FieldSet which is added to the form then submitting a form is not possible.

      Possible problem is in double post validation, that is - first you submit form with auto complete field and if you try to submit with submit button afterwards, submission fails (method form.onSubmitCheck(this, pagePath) returns false).

        Activity

        Hide
        sabob Bob Schellink added a comment -

        Hi Ivan,

        Thanks your analysis is correct. The Ajax call to the server seems like a normal form submit and Click regenerates a different double post token.

        To solve this we need a more robust check for Ajax callbacks.

        Doing some research there is the de-facto standard header : "X-Requested-With: XMLHttpRequest" supported by Prototype, JQuery, Mootools, YUI, MockiKit, Dojo 1.1.
        Rico is included in this list since its built on Prototype.

        Here are some articles for those interested:

        http://www.dev411.com/blog/2006/06/30/should-there-be-a-xmlhttprequest-user-agent

        http://raphaelstolt.blogspot.com/2007/03/using-plugin-system-of-zend-framework.html

        Please note that there is an ajax "standards" organization; http://www.openajax.org/index.php which might standardize on another header.

        If users want to use a Ajax lib which does not support this header, its usually easy enough to hack javascript

        Implementation wise we could do Context#isAjaxRequest();

        Show
        sabob Bob Schellink added a comment - Hi Ivan, Thanks your analysis is correct. The Ajax call to the server seems like a normal form submit and Click regenerates a different double post token. To solve this we need a more robust check for Ajax callbacks. Doing some research there is the de-facto standard header : "X-Requested-With: XMLHttpRequest" supported by Prototype, JQuery, Mootools, YUI, MockiKit, Dojo 1.1. Rico is included in this list since its built on Prototype. Here are some articles for those interested: http://www.dev411.com/blog/2006/06/30/should-there-be-a-xmlhttprequest-user-agent http://raphaelstolt.blogspot.com/2007/03/using-plugin-system-of-zend-framework.html Please note that there is an ajax "standards" organization; http://www.openajax.org/index.php which might standardize on another header. If users want to use a Ajax lib which does not support this header, its usually easy enough to hack javascript Implementation wise we could do Context#isAjaxRequest();
        Hide
        sabob Bob Schellink added a comment -

        Need to fix in 1.4.1 as well as 1.5.M1

        Show
        sabob Bob Schellink added a comment - Need to fix in 1.4.1 as well as 1.5.M1
        Hide
        sabob Bob Schellink added a comment -

        fixed in trunk and backported to 1.4.1

        Resolving issue for now. If there are further issues feel free reopen this issue or create a new one.

        Show
        sabob Bob Schellink added a comment - fixed in trunk and backported to 1.4.1 Resolving issue for now. If there are further issues feel free reopen this issue or create a new one.
        Hide
        medgar Malcolm Edgar added a comment -

        Causes issues if form is being used in an AJAX context. This AJAX submitCheck ignore should probably only occur on GET requests and not POST requests.

        Current form code:
        // CLK-333. Don't regenerate submit tokens for Ajax requests.
        Context context = getContext();
        if (context.isAjaxRequest())

        { return true; }
        Show
        medgar Malcolm Edgar added a comment - Causes issues if form is being used in an AJAX context. This AJAX submitCheck ignore should probably only occur on GET requests and not POST requests. Current form code: // CLK-333 . Don't regenerate submit tokens for Ajax requests. Context context = getContext(); if (context.isAjaxRequest()) { return true; }
        Hide
        sabob Bob Schellink added a comment -

        Hi Malcolm,

        Perhaps, but how will one handle the security check in an Ajax context? Generally one would do the security check and perform a redirect to another page. Using Ajax, one would post the form and "repaint" the result from the server. If there is a redirect, you won't repaint the form but the result of the redirected page. So you post the duplicate form and get back an HTML page which you probably do not want?

        For duplicate submissions I think it's best if the client side handles it, ie show a loading indicator which blocks the form and duplicate submissions.

        I don't object to the change in code though, just not sure how folk will handle the onSecurityCheck using Ajax.

        Kind regards

        Bob

        Show
        sabob Bob Schellink added a comment - Hi Malcolm, Perhaps, but how will one handle the security check in an Ajax context? Generally one would do the security check and perform a redirect to another page. Using Ajax, one would post the form and "repaint" the result from the server. If there is a redirect, you won't repaint the form but the result of the redirected page. So you post the duplicate form and get back an HTML page which you probably do not want? For duplicate submissions I think it's best if the client side handles it, ie show a loading indicator which blocks the form and duplicate submissions. I don't object to the change in code though, just not sure how folk will handle the onSecurityCheck using Ajax. Kind regards Bob

          People

          • Assignee:
            medgar Malcolm Edgar
            Reporter:
            ivanf Ivan Furdi
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development