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. SubmitBean.java
        1 kB
        Ted Goddard
      2. submitTest.jspx
        0.8 kB
        Ted Goddard

        Activity

        Deryk Sinotte created issue -
        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.
        Deryk Sinotte made changes -
        Field Original Value New Value
        Salesforce Case []
        Fix Version/s 2.0-Beta [ 10032 ]
        Assignee Priority P1
        Assignee Ted Goddard [ ted.goddard ]
        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.
        Ted Goddard made changes -
        Attachment SubmitBean.java [ 12182 ]
        Attachment submitTest.jspx [ 12183 ]
        Deryk Sinotte made changes -
        Link This issue blocks ICE-2697 [ ICE-2697 ]
        Ken Fyten made changes -
        Salesforce Case []
        Fix Version/s 2.0-Beta [ 10231 ]
        Fix Version/s 2.0-Alpha3 [ 10032 ]
        Assignee Priority P1
        Ken Fyten made changes -
        Link This issue depends on ICE-2697 [ ICE-2697 ]
        Ken Fyten made changes -
        Link This issue blocks ICE-2697 [ ICE-2697 ]
        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
        Ken Fyten made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        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.
        Ken Fyten made changes -
        Salesforce Case []
        Assignee Priority P2
        Assignee Ted Goddard [ ted.goddard ] Mircea Toma [ mircea.toma ]
        Ken Fyten made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        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.
        Mircea Toma made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        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?
        Ken Fyten made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Ken Fyten made changes -
        Salesforce Case []
        Component/s Framework [ 10013 ]
        Ken Fyten made changes -
        Fix Version/s 2.0-Beta2 [ 10242 ]
        Fix Version/s 2.0-Beta1 [ 10231 ]
        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.
        Mircea Toma made changes -
        Assignee Mircea Toma [ mircea.toma ] Deryk Sinotte [ deryk.sinotte ]
        Ken Fyten made changes -
        Link This issue depends on ICE-2697 [ ICE-2697 ]
        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 .
        Deryk Sinotte made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Fix Version/s 2.0.0 [ 10230 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Assignee Priority P2

          People

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

            Dates

            • Created:
              Updated:
              Resolved: