Attached test case that shows this issue. Note, the icefaces, ace, and compat jars need to be added into the war for it to run.

Steps:

• Load welcomeICEfaces.jsf
• Attempt a double click on the Submit button, two submits will be fired. Removing the submitMonitor, the same double click is blocked.

Modified ace:submitMonitor component to stop disabling the blockUI feature setup by the core.

Verified with ICEfaces 4 trunk r44469. Tomcat 7. When testing with EE-3.3.0 branch the Submit is only registered once (fixed) but the submit monitor is not activated and stays in an idle state.

Removed the disabling of Element.on***** callbacks since the blocking of the submit function is enough (and any interference between these two strategies is avoided).

Verified ICEfaces 4 trunk, ee-3.3.0 maintenance branch r44481. Tomcat 7, IE 11, FF 34, Chrome 41.

Is there a way how you can NOT trigger blockUIOnSubmit for a specific form if the parameter 'org.icefaces.blockUIOnSubmit' is set to 'true'?

If there is, please share it with me, hasn't been able to find a solution.

If not, then this fix made the only way to make a specific form NOT to trigger the blocking UI, if the parameter 'org.icefaces.blockUIOnSubmit' is set to 'true'.

Shouldn't it be better to make the <ace:submitMonitor with blockUI="ANY_VALUE"> to overwrite the parameter org.icefaces.blockUIOnSubmit, because of <ace:submitMonitor> can be specified for every form, and blockUIOnSubmit can only be specified for every page (NOT for every form). Meaning <ace:submitMonitor> is more specific then blockUIOnSubmit.

A better solution to this problem would be not to use <ace:submitMonitor blockUI="@none" /> if you want the UI-Block to appear.
Why would you want to put 'blockUI="@none"' if you still want to have a blocking UI?

Oscar,

The blockUIOnSubmit configuration is a global (or per page) configuration and is not meant to be mixed with the ace:submitMonitor component. The ace:submitMonitor provides a much more flexible capability and if you require per-form configuration you should adopt it exclusively and avoid blockUIOnSubmit.

Note that you CAN enable/disable the blockUIOnSubmit feature on a per-page basis as well.
e.g.
<h:body>
<icecore:config blockUIOnSubmit="true|false"/>
...

See the <icecore:config> Wiki topic for details: http://www.icesoft.org/wiki/display/ICE/config

Hello Ken,

The blockUIOnSubmit configuration is a global (or per page) configuration and is not meant to be mixed with the ace:submitMonitor component.

Why?

I still don't understand why this is done, as it has been a feature. Now it is only possible to do blockUIOnSubmit for the whole application OR specify it to every component or page (a lot of redundant work!). But what you cannot do, is to set a blockUIOnSubmit for the whole application and then specify for a specific use case something else.

This is your own comment: "There should be an order of precedence such that a more specific monitor will override a more general one, in cases where more than one monitor might be in effect for the same submit." [Comment on ICE-7740]

Isn't the component ace:submitMonitor more specific than the global setting blockUIOnSubmit?

In my scenario, I have over 500 forms on over 300 pages. I want all of the forms to be such that you should block the UI when you do submit something. That is why the setting org.icefaces.blockUIOnSubmit is really good here. But now I have one form that I shouldn't block the UI when submitted. So the only way for me to make it possible is to refactor the whole application?

If there isn't a specific reason why the components ace:submitMonitor attribute blockUI shouldn't override the global setting, then it would be a good idea to fix this.

P.S. What did you want to say with the icecore:config link?

See the <icecore:config> Wiki topic for details: http://www.icesoft.org/wiki/display/ICE/config

I meant as a workaround for your solution you could factor your application so that the page that contains the one form that doesn't want blockUIOnSubmit doesn't use it via configuring it on each page instead of via the global config parameter.

In this specific use case, that workaround isn't possible because of the one form I don't want blockUI to appear on, is on the page that is the base of every page. Which means that the only way to fix this problem is to take away the global config blockUIOnSubmit and add the component ace:submitMonitor to every form.

But thanks for proposing a solution.

Just to clarify:
(1) If the global config blockUIOnSubmit is set to true, you cannot disable UIBlock for a form with ace:submitMonitor?
(2) If the global config blockUIOnSubmit is set to false, you can enable UIBlock for a form with ace:submitMonitor?
(3) If the global config blockUIOnSubmit is set to true, you can disable UIBlock for a page with <icecore:config blockUIOnSubmit="false"/>?
(4) If the global config blockUIOnSubmit is set to false, you can enable UIBlock for a page with <icecore:config blockUIOnSubmit="true"/>?
(5) If the global config blockUIOnSubmit is not specified, you can set UIBlock for a form with ace:submitMonitor ?
(6) If the global config blockUIOnSubmit is specified, you cannot set UIBlock for a form with ace:submitMonitor?
(7) If the global config blockUIOnSubmit is not specified, you can set UIBlock for a page with <icecore:config blockUIOnSubmit="true|false"/>>?
(8) If the global config blockUIOnSubmit is specified, you can set UIBlock for a page with <icecore:config blockUIOnSubmit="true|false"/>?
(9) If <icecore:config blockUIOnSubmit="false"/> is specified for a page, you can enable UIBlock for a form with _ace:submitMonitor?

Thanks in advance.

P.S. Just to clarify, I have many forms on one page, and not only one form per page. and I only want one form that shouldn't block the UI. For more information check out my StackOverflow question: setting blockuionsubmit for a specific form

P.P.S. If statements (1) and (2) are true, then the configuration blockUIOnSubmit is mixed with the component ace:submitMonitor. making your own statement false:

The blockUIOnSubmit configuration is a global (or per page) configuration and is not meant to be mixed with the ace:submitMonitor component.