The component ace:submitMonitor is useless nowadays due to the changes in this bug: ICE-10518. Now the element ace:submitMonitor with the attribute blockUI=@none (Which is specific for every form) will not stop the blockUIOnSubmit setting (Which is specific for every page).

I've added a comment to the issue here: ICE-10518 comment.

I've also created a new issue about this: ICE-11454.

Added capability for old SubmitMonitor javascript instances to clean themselves up, and not interfere with subsequent instances, which are created when the ace:submitMonitor properties are changed or when the component is updated. This ties into the onElementUpdate feature that was ported into this branch.
Tested against QA submitMonitor test app, specifically submitMonitorFor, submitMonitorRepeat pages, and a hybrid, with the Repeat sections that cause large updates added into the For page.
Two caveats with the cleanup functionality found are:
1. ICE-8580 onElementUpdate is not called when the document body is updated
2. ICE-8579 There is no way to remove the submit listeners, so right now instances are leaked, but flag themselves to discontinue processing
patch branch
Subversion 30882 submitmonitor.js
Subversion 30883 application.js

Updated the active and idle icons.
This JIRA is now resolved.

We never know how long a request will take. We could delay 500 ms, and then the request will only take a further 100 ms, and it will be a flicker. It's important to not delay too long, so the user won't think the system is laggy or that they fail to initiate the submit.

I've noticed while playing with the new component that it can be quite jarring if the modal layer / busy indicator is displayed during a very short-lived submit (<500 millis) as it appears as a quick flash that might even cause problems for anyone susceptible to seizures. I would suggest that we adjust the component behaviour to delay presentation of the modal layer and activity indicator/message until at least 500 millis have transpired, thus avoiding the quick flashing behaviour.
Here is a reference on this subject:

What sort of Progress Indicator will you use?
A well known set of guidelines is summarised in Jakob Nielsen's Usability Engineering. As a quick summary:

• If the delay is less than 0.1 second, the user will feel it's instantaneous. No feedback necessary.
• If the delay is between 0.1 second and 1 second, the user will notice it but it won't break their flow of thought. No feedback necessary.
• If the delay is between 1 and 10 seconds, the user's flow of thought is interrupted as they await the response. Basic feedback necessary, i.e. an indication that a delay is occurring. Ajax examples include animated icons and simple text messages.
• If the delay is greater than 10 seconds, the user will want to proceed onto other tasks. Detailed feedback necessary. Ajax examples include progress meters and messages showing current state.
  The precise figures may require some adjustment and I suspect a web context requires them to be dropped a bit. For example, users will probably want some feedback for a delay of 0.5 seconds rather than 1 second, and more detailed information is probably appropriate after 2-3 seconds rather than 10 seconds.

If we are concerned about not blocking user input for the first 500 millis, perhaps we could implement user event blocking immediately and only style the overlay darker and display the activity monitor/message after 500 millis.