ICEfaces
  1. ICEfaces
  2. ICE-5328

Develop a test scenario and application for examining double submit

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Alpha2
    • Fix Version/s: 2.0-Beta2, 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 2

      Description

      The term double submit is generally meant to mean users interacting more than once quickly in succession causing two or more form submissions when only one is required. With ICEfaces 1.x, this was considered to be an issue in certain scenarios and some strategies were developed to deal with. This task is aimed at coming up with one or more double submit scenarios and a test application that can reproduces those scenarios so that we can see how the current implementations of JSF 2 and ICEfaces 2 deal with them. Once we have generated and captured some data, we'll discuss concrete ways of dealing with them as necessary.
      1. submitTest.jspx
        0.8 kB
        Ted Goddard
      2. SubmitBean.java
        1 kB
        Ted Goddard

        Activity

        Hide
        Deryk Sinotte added a comment -

        Initially assigning to Ted for the discussion part. Will likely re-assign back to Deryk for the development of a test application. The priority is set relatively high as we'd like to have the data as soon as possible so we can determine how much work we may need to do.

        Show
        Deryk Sinotte added a comment - Initially assigning to Ted for the discussion part. Will likely re-assign back to Deryk for the development of a test application. The priority is set relatively high as we'd like to have the data as soon as possible so we can determine how much work we may need to do.
        Hide
        Ted Goddard added a comment -

        Previous double submit test case with application-level fix.

        Show
        Ted Goddard added a comment - Previous double submit test case with application-level fix.
        Hide
        Joanne Bai added a comment -

        Results on icefaces/trunk and glimmer (using tomcat 6.0.26 + FF3.6)

        1. icefaces/trunk (revision 21755) test result

        • Without blockUIOnSubmit=true in web.xml, text "double submit" can seen outputting to server console
        • With blockUIOnSubmit=true, "double submit" is not seen

        Test app has been added to: repo\qa\trunk\Regression\Manual\ICE-5328

        2. Glimmer (revision 21786) test result

        Do not do anything to web.xml. Just test the application - text "double submit" can seen outputting to server console.

        Test app has been added to: \repo\qa\trunk\Regression-Icefaces2\Manual\ICE-5328

        Show
        Joanne Bai added a comment - Results on icefaces/trunk and glimmer (using tomcat 6.0.26 + FF3.6) 1. icefaces/trunk (revision 21755) test result Without blockUIOnSubmit=true in web.xml, text "double submit" can seen outputting to server console With blockUIOnSubmit=true, "double submit" is not seen Test app has been added to: repo\qa\trunk\Regression\Manual\ ICE-5328 2. Glimmer (revision 21786) test result Do not do anything to web.xml. Just test the application - text "double submit" can seen outputting to server console. Test app has been added to: \repo\qa\trunk\Regression-Icefaces2\Manual\ ICE-5328
        Hide
        Ken Fyten added a comment -

        Need to analyze the test scenario to see why the JSF 2 client bridge queue doesn't prevent this, and determine if we need to adopt the "blockUIOnSubmit" feature from 1.8 in 2.0.

        Show
        Ken Fyten added a comment - Need to analyze the test scenario to see why the JSF 2 client bridge queue doesn't prevent this, and determine if we need to adopt the "blockUIOnSubmit" feature from 1.8 in 2.0.
        Hide
        Mircea Toma added a comment -

        The Glimmer queue prevents having requests issued until the currently issued request receives its corresponding response. Once the response is received the setup of the next request is picked up from the queue, the request is prepared and then issued.

        In conclusion, the Glimmer queue will prevent double submit but it won't block the interaction with the UI during a request-response interval.

        Show
        Mircea Toma added a comment - The Glimmer queue prevents having requests issued until the currently issued request receives its corresponding response. Once the response is received the setup of the next request is picked up from the queue, the request is prepared and then issued. In conclusion, the Glimmer queue will prevent double submit but it won't block the interaction with the UI during a request-response interval.
        Hide
        Ken Fyten added a comment -

        This doesn't explain why the "double-submit" test fails then when running on Glimmer. Can you explain how we are getting double-submits even though the queue should prevent that?

        Show
        Ken Fyten added a comment - This doesn't explain why the "double-submit" test fails then when running on Glimmer. Can you explain how we are getting double-submits even though the queue should prevent that?
        Hide
        Mircea Toma added a comment -

        The 'double-submit' test uses a counter that has its value incremented every time a DOM update is received. On submit the server receives the value of the counter which is compared against the value it holds on the server, when counter values have the same value the test assumes that there are additional submits sent before the browser received the update corresponding to the first submit.

        The test fails when running with JSF 2 bridge queue because the submits that are put into the queue have their set of parameters already built. Submits taken out of the queue will be issued after the DOM updated is received but the parameters will contain the counter value the way it was before the update was applied.

        In conclusion, the JSF 2 queue cannot really be used as a double-submit protection. Changing queue's behavior by calculating the parameters lazily, just before the submit is issued, will introduce other subtle problems (which we discovered in the past).

        Porting the double-submit feature from 1.8 seems the only viable solution.

        Show
        Mircea Toma added a comment - The 'double-submit' test uses a counter that has its value incremented every time a DOM update is received. On submit the server receives the value of the counter which is compared against the value it holds on the server, when counter values have the same value the test assumes that there are additional submits sent before the browser received the update corresponding to the first submit. The test fails when running with JSF 2 bridge queue because the submits that are put into the queue have their set of parameters already built. Submits taken out of the queue will be issued after the DOM updated is received but the parameters will contain the counter value the way it was before the update was applied. In conclusion, the JSF 2 queue cannot really be used as a double-submit protection. Changing queue's behavior by calculating the parameters lazily, just before the submit is issued, will introduce other subtle problems (which we discovered in the past). Porting the double-submit feature from 1.8 seems the only viable solution.
        Hide
        Deryk Sinotte added a comment -

        The test app has been developed and a decision to port the UI blocking feature from ICEfaces 1.8 to ICEfaces 2 has been made. The ticket for that work is ICE-5987.

        Show
        Deryk Sinotte added a comment - The test app has been developed and a decision to port the UI blocking feature from ICEfaces 1.8 to ICEfaces 2 has been made. The ticket for that work is ICE-5987 .

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Deryk Sinotte
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: