The blocking progress popup components intent is to block user interaction during form submission. It is assumed the blocking progress popup will be indeterminate in nature and act on the ICEfaces bridge event ice.onBeforeSubmit and ice.onAfterUpdate to control visibility. A new mobi component should be created and have the following characteristics.

• Assignable to mobi:commandButton using a 'for' attribute binding to insure the dialog will only show when configured to do so.
• Default style would lighten screen with and show an indeterminate progress animated image.
• Well defined layout and CSS definitions to make the dialog easily skinnable.
• Child elements of the component would render in the popup.
  The JSF representation of the component would be as follows.

<mobi:submitNotification for="someButton" >
<h:outputText value="Processing" />
</mobi:submitNotification>
<mobi:commandButton id="someButton" actionListener="#

/>

could it be considered to do one of the following for this component?

<mobi:commandButton id="someButton" actionListener="#

notificationPanel="notifOne"/>

<mobi:submitNotification >
<h:outputText value="Processing" />
</mobi:submitNotification>

?? Much easier to implement since the process begins and ends with the request originating from the commandButton and this would be very similar to panelConfirmation.

was also wondering if we could somehow make use of the mobi:ajax tag onStart is executed directly before the ajax submit and onComplete is executed directly after completion of the ajax request.

<mobi:commandButton id="someButton" actionListener="#

notificationPanel="notifOne"/>

<mobi:submitNotification id="notifOne">
<h:outputText value="Processing" />
</mobi:submitNotification>

Keeping it consistent with confirmation panel I think is key. You could consider the mobie:ajax tag but the end user probably doesn't need that level of control. The component could popup and hide with bridge event ice.onBeforeSubmit and ice.onAfterUpdate or something similar. Pretty sure ice.onBeforeSubmit gets called before the request is sent as the services group has built several composite components that do the same thing.

is it possible to have both panelConfirmation and notificationPanel on same commandButton?

I think it would be possible. the submit notification panel wouldn't popup unless the accept button was pressed.

OK..that's kind of what I figured....
Am reworking the command button & panelconfrimationfor all these variations....panelConfrimation, submitNotificaiton, ajax behaviours, singleSubmit....making sure I have all combinations of these covered.

Updated the submitNotification component to use new auto center/scroll code and apply the style pass through attribute to the the popup container. Also updated the showcase example for a typo in the attribute "submitNofification".

complete as per Jira. Any further proposed work should have new Jira number