Attached test case that shows this issue. The icefaces, icefaces-ace, icefaces-compat jar files need to be added into the war to run.

Steps:

• Load page1.jsf (I recommend opening the browser console to see the issue better).
• Click on the Continue button.
• In the console it will show the ui-blocker displayed, then it is hidden. After a few seconds page2 content is shown.

It's likely the cause of this change are from ICE-9323.

There was a change in the aforementioned ICE-9323 so that the UI blocker is hidden "onBeforeUpdate", whereas previously it was "onAfterUpdate".

This has an unintended consequence in the case of a Redirect to a slow page. As in a faces-config navigation rule that has <redirect/>, or a commandButton action with "?faces-redirect=true" as part of the returned string.

Going from the code sample, if the user clicks "Continue" they POST to the server. But the response from that POST is content that simply says "redirect to page 2". But since the POST is completed the "onBeforeUpdate" will fire, closing the UI blocker.

Then the browser will do a GET of page 2, with the UI unblocked at this point. Normally on fast pages and requests this isn't a problem.

However if page 2 is extremely slow to load (such as a lot of work done on initialization or getters), such as the GET taking 10 seconds, that means the user can interact with page 1 (unblocked) for those 10 seconds.

Reverting the change (at the end of icefaces/core/src/main/javascript/blockui.js) to "onAfterUpdate" fixes this issue, but may potentially introduce the old issue with panelPopup that ICE-9323 was meant to fix.

Might need to make this configurable as to whether the onbeforeupdate vs onafterupdate is used, with onafterupdate being the default?

The blocking of the UI seems to work as expected. The UI unblocking occurs after the redirect command is received by the JSF bridge, only after that the request for the next page is issued by the browser (not the bridge). Since the (GET) request is issued by the browser itself the callbacks that block UI registered with bridge are not invoked.

Modified the bridge to also start the blocking of the UI when "beforeUnload" event is triggered, which can be caused by page navigation or reload.

Verified functioning as expected Icefaces ee-3.3.0 maintenance branch r40997, Tomcat 7, all browsers.