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.

Previous double submit test case with application-level fix.

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

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.

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.

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?

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.

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.