We decided that this issue is just an undesired but unavoidable side-effect of the UI blocker feature. The UI blocker will be disabled by default, unlike how original issue ICE-4203 states.

I posted a suggestion to ICEfaces forum.

http://www.icefaces.org/JForum/posts/list/12191.page#48623

Re-opening to see if any improvements can be made in the future.

is there any known workaround for this issue?

Is the fix coming anytime soon? This is badly wanted in our product. Without setting blockUIOnSubmit="true", there are all sorts of issues with setters getting called with null values on double clicking buttons.

Setting blockUIOnSubmit="true" fixes that, however, the cure turns out to be worse than the disease in that user's first click on any buttons in that page is a no-op for him/her and is much worse than original issue from user perspective.

I also need a fix for this very badly. As I suggested, I hope we can enable it only for a specified actions.

I hope ICEfaces developers have a concern about this issue and please let us know whether they are working on this.

Thanks

There are some related notes in ICE-2697 around a possible solution that could be implemented.

Disable double submit locking when first submit is triggered by "onblur" events. This way buttons that are clicked right after an input text loses focus will work as expected.

The last commit causes the following new regression: ICE-5827.

ICE-5827 is resolved.

However, with latest code and "blockUIOnSubmit=true", clicking the "Extended Components" demo link on the left-side tree of the Facelets Enhanced Comp. Showcase fails to open the demo panel. This works fine when "blockUIOnSubmit=false", however.

The last issue was caused by a double submit initiated when clicking on the header of panel collapsible. navigation.jspx file has a command link in the header of the panel which triggers a submit when clicked, but lets the event to propagate to the panel collapsible header which will trigger a submit as well. When blockUIOnSubmit is enabled the second submit is blocked, unfortunately the last submit toggles the state of the panel, first submit doesn't change anything in the state of the components or application.

The fix applied simply replaces ice:commandLink found in the header of panel collapsible with an ice:outputText.

We should tighten up the logic of this such that a submit (partial) triggered by an onblur will cause the UIblock state to be invoked by the next submit (regardless of its origin). This will allow the use-case of an inputText with partial-submit=true having focus, and then the user clicking on a commandButton to work as expected (first partial-submit goes through, second full-submit goes through and invokes the UIBlocker, preventing further submits until after the second response is returned). In addition, it will also prevent the double-submit exposure risk of allowing a user to trigger numerous partialSubmits sequentially (avoiding the UIblock), as is possible with the current logic.

I also noticed that we've disabled the UI blocking DIV with the last changes. I think this is problem in that without the DIV blocking subsequent user-interactions it is possible/likely that users may make additional state changes to the browser UI components (that have partialSubmit=true specified) that will never be submitted to the server, resulting in a state-delta between what the browser UI indicates and what the server thinks.

For example, imagine a form with numerous ice:selectOneMenu components, each with partialSubmit=true. Without the UIBlocking DIV, the user could change the selected value of one or more of the components while a previously triggered partial-submit is still being processed, resulting in the component indicating selected values on the client that are never submitted to the server. With the blocking DIV present, the user will not be able to change the state of the browser-side components, avoiding this possibility. It also provides feedback to the user that they need to wait for the current submit operation to complete before proceeding with additional changes to the form, etc. The hourglass combined with the inability to interact with the page combine to inform the user that they must wait before proceeding.

The UI blocking DIV should be invoked at the same time that the submit block is, of course.

Refactored onReceive callbacks to be registered per request to avoid any mixups when resposes are received out of order. Wired up UI blocker in the bridge instead of having it abstracted as indicator in the status manager code.

Re-opened. Current code is working well for blocking mouse-based input. However, we now need a solution that prevents keyboard navigation/entry while the blocker is enabled.

Blocked keyboard interaction by disabling the key event handlers (keypress,keyup,keydown) temporarily on elements that can receive focus.

The latest changes are working well. However, the keyboard event disabling feature seems to be occurring regardless of the 'blockUIOnSubmit="true"' setting. It should only be invoked when 'blockUIOnSubmit="true"'.

Disable keyboard blocking when com.icesoft.faces.synchronousUpdate feature is disabled.

Verified successfully on ICEfaces/trunk revision 21855, using Tomcat6.0.26 + FF3.6 and IE8

Test app has been committed to repo\qa\trunk\Regression\Manual\ICE-4308

Any plans to implement my suggestion? http://jira.icefaces.org/browse/ICE-4308?focusedCommentId=26593&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_26593

See ICE-5817 for follow-up on your suggestion, Isuru.

Hi Ken, Thanks for informing and considering my suggestion.