Ok, that's what I thought. Actually that's not really an issue per se, it's just the fact that the submit monitor takes some time to uninstall/install itself on the page. All the callbacks of the previous submit monitor have to finish executing before handing off control to the new incarnation of the component, which has to do its own set-up, involving modifying the submit function in the bridge and registering a bunch of callbacks that are executed before and after submitting and after the update is completed. So, it's actually not the case that you have to click the button twice for the submit monitor to work at first. If you just wait long enough for the component to rebuild itself in the client (e.g. 3 seconds) right after changing any of the settings in the Configuration Panel, the submit monitor will be activated the first time you click the button. Because in a real-world scenario it wouldn't be likely that the submit monitor change dynamically at the user's request, this can't be considered as an issue, and this JIRA will be marked as fixed.

r44732: committed fix to the 4.x trunk.

Added 4.1 target as well.

By "Usually have to press the submit button twice" do you mean that for every 2 times that you press the button only one time the submit monitor is activated for as long as you continue to do that? or, does this happen only right after you change the value of the "What to block" menu and then every time you click will activate the submit monitor?

I had noticed this happening even before applying these fixes, but only right after changing the value of "What to Block", then the submit monitor was activated normally for every click. This is because all the set-up that the component has to do, since it has to override the main submit function as well as registering a bunch of callbacks, in order to function properly.

Tested with ICEfaces EE-3.3.0.GA_P03 tag, maintenance branch, r44720.
ICEfaces was built using ant allclean world and core folders are up to date.
DeltaSubmit = true OR false: Usually have to press the submit button twice when Region to Listen to is set to Demonstration Panel and Region to block is set to Configuration and Demonstration Panels or Whole page.

ICEfaces 4 trunk r44720 - demo stops working after changing the What to Block selection more than once.

r44719, r44720: modified the previous fix to work more reliably and to also prevent issues when using blockUI=@source.

The previous fix solved the original issue, but it introduced a new issue when blockUI=@source. This new fix solves both issues and works more reliably in general. Note that you need to update the core folder too when testing this fix.

Tested with ICEfaces EE-3.3.0 tag and maintenance branch r44715 with deltaSubmit=true. This issue is not yet resolved. When changing the "What to block:" selection a few times the submitMonitor no longer appears in the demo.
To reproduce:
1.) Build EE-3.3.0 showcase with deltaSubmit=true.
2.) Navigate to ace:submitMonitor > Overview
3.) After the demo loads press the submit button (do not change settings). The submitMonitor works as expected.
4.) Change the "What to block: " selection to "Only the submitting component". Press the submit button again. This time the submitMonitor may not appear over the submit button as expected. If it does, press the Submit button again and the submitMonitor likely will not appear.
5.) Change the "What to block: " selection again and press the Submit button. The submitMonitor does not appear as expected.
This issue appears at some point eventually, you may have to try a few submits before it occurs.
Also an issue with ICEfaces 4 trunk and deltaSubmit=true.

Committed fix to the 3.3 EE maintenance branch at revision 44714 and to the P03 tag at revision 44713. Modified overriding submit function to pass the element via document.getElementById() to the isParentElement() function, since the element passed to the submit function when deltaSubmit=true is a cloned element inside the deltaSubmit form, which doesn't help determine what isParentElement() is trying to determine.

Testing notes: please also check if this issue is present in the 4.x trunk, in order to apply this fix there as well, if necessary.