Would also be nice if the activity indicator itself could be customized by the application, for example, could be as simple as a spinning disc or complex as multiple components or text messages displayed over the region. Linked ICE-7262 for this aspect.

Specifications:

Shows an indicator based on the state of form submits iniQated by components in regions of the page monitored by this component.

The component works by monitoring all form submits processed by the standard JSF 2 bridge. In this way, it can be used for form submits triggered by any JSF2 compaQble mechanism, and is not limited to submits triggered by ICEfaces ICE or ACE components.

• This component can be configured to monitor the entire page (default).
• This component can be configured to monitor one or more specific components within the page.
• Multiple ace:activityIndicator components may be used on the page, for different components or containers(regions), each with their own activity message or facet contents are required.

The component will support notifications for the following states:
­‐ SubmitPending: displays notification message while a form submit is in­‐progress. -­‐ ServerError: displays a custom error message if Server Error occurs.
-­‐ NetworkError: displays a custom error message if Network Error occurs.
-­‐ SessionExpired: displays a custom error message if SessionExpired error occurs.

By default, the component will render an animated image icon whenever it is in a "SubmitPending" or busy state.
-­‐ The "showIcon=true/false" (default=true) aRribute will be used to control this behavior.
-­‐ The image icon will be customizable / styleable via CSS.

The component will optionally accept a simple string value for "busy" status as an aRribute (ex. "busyLabel"). When specified, this label will be rendered centered over the page or component while the submit is in progress ("SubmitPending" state is active). This mode is the simplest to use, most common use-­‐case for the component.
In addition, for additional flexibility, the component can optionally accept facets that correspond to each state. Each facet region can contain arbitrary components for maximum flexibility. When specified, the facet(s) will be rendered centered over the page or component while the state that they represent is active.
Facets for each supported activity state will be supported:
­‐ SubmitPending (normal busy state while an ajax submit is in­‐progress)
-­‐ ServerError (display custom error message if Server Error occurs)
-­‐ NetworkError (display custom error message if Network Error occurs)
-­‐ SessionExpired (display custom error message if SessionExpired error occurs)

The component will have the ability to position its output centered over the region that is monitoring activity for (full page or component) via the "autocenter" attribute.
-­‐ When "autocenter=true" (default) the indicator icon, busyLabel, or facets will be centered over the region being monitored.
-­‐ When "autocenter=false" the component will render as it is positioned/styled via CSS on the page.

The activity indicator can optionally block user interaction with the components under the activityIndicator region (either the entire page or the component associated with the activityIndicator) to prevent unintended events from being fired while waiting for a previously triggered event to be processed.
-­‐ This will be controlled via the "blockUIOnSubmit=true/false" attribute (default=true).
­‐ The UI blocking mechanism will render a semi­‐transparent layer over the blocked region. -­‐ Keyboard interaction within the blocked region will (optionally) also be blocked.

The mouse cursor will optionally change to an hourglass while over the page or component while the "SubmitPending" state is active.
-­‐ This behaviour can be configured via the "showHourGlass=true/false" (default=true) attribute.

It's my understanding that when blockUIOnSubmit=false, then the component will always be shown, and when blockUIOnSubmit=true it is only shown during the submit, and is shown as a modal popup. How does this interact with the autocenter property? Does autocenter only apply when blockUIOnSubmit=true and is showing the modal popup, and autocenter controls where the popup goes? As well, I can see two centering strategies, on over the submitting component and one centered over the whole view, like ace:dialog with position=center.

Right now the bridge has its own existing API for specifying messages for when the session is expired, etc. And it includes a button for refreshing the display. Are we supplanting that, or duplicating that? Should be have the refresh or reload button as well?

As far as I'd envisioned it autocenter only applies when UI blocking is enabled.

Positioned in the middle of the whole view is how centring is implemented- because the size of its container overlay is the full view width- when using 'scoped' UI blocking to block particular container if the overlay is sized/positioned to the region the label will still be centred appropriately. Or are you suggesting blocking the whole view but "centring" the indicator/label over the submitting component?

I have to ask Ken to clarify regarding the session expired events. I'd expected that ours if used would supersede the bridge handling - although I'd considered blocking the existing bridge handling 2nd revision feature.

I've confirmed with Ken that the session expired handling of this component, if present, would disable the native bridge handling.

I was distracted from this issue by a Williams support request today, so I wasn't able to commit much more than I had already started yesterday.

The component as committed has implemented the blockUI toggle, 'centrered' toggle, the active and idle labels and fixed images.

The component still has to:

• add the ability to be scoped to requests starting from components within a particular container
• add listeners to transition into the session expired and error states
• add configurable images properties
• add facets to define monitor states
• add showIcon toggle
• add showHourglass toggle

Ok to summarise, autocenter only applies when blockUIOnSubmit=true. And so we then have the four cases, of the for and autocenter properties interacting, when blockUIOnSubmit=true. When for is not used, submit intercepting is global, and when it is used, it's specific to the components specified, and all their children.

for not set (global), autocenter=false
This one's obvious, set the blocking overlay over the whole view, and don't center the popup, let it show wherever it was placed.

for not set (global), autocenter=true
Set the blocking overlay over the whole view, and center the popup. The question is, should it be centered over the view, or over the submitting component. This mode could favor the view centering.

for set (specific), autocenter=false
I would think that we always want the overlay over the whole view when using blockUIOnSubmit, and not just over a submitting component. And let the popup show when it's already positioned.

for set (specific), autocenter=true
Again, overlay over the whole view, and again the question of what to center on. An argument could be made for favoring the submitting component.

I think that autocenter should be an enumeration, renamed autoPosition, where the app specifies centerOnView, centerOnComponent. And possibly in the future we find that covering a submitting component is actually a pain since it can't be seen while waiting, so we may add in the future options for placing it above or below the submitting component.

Clarified from discussing with Nils and then Ken:

blockUI = @all / @none / panelId. default is @all
for = submittingButtonId. default when unspecified is all submitting components
autoCenter = true means center on the overlay, otherwise it just shows where it is.

We've changed blockUI from a Boolean to a String that specifies what the overlay will cover. @all is the whole view, and id would tend to be some sort of container, and @none would mean there is no overlay, like false meant before. We want to be able to specify a container to put the overlay on, instead of just having it over the submitting component, since the submitting component can be something small like a commandButton, that would be too small for the labels, images or facets to show on.

(Q) In theory we could add a @source option for still doing the overlay over whatever specifically is doing the submit.

for will be a space delimited list of components, where if they cause the submit, or some component within them, then we take action. If unspecified then we take action from all submits.

(Q) When for applies to a specific component, and another one we're not monitoring does a submit, then it's clear that we shouldn't bring up the blocking overlay. But what about when blockUI is @none and the monitoring component is always showing itself without an overlay. Should the monitor continue to show idle during the unmonitored submit? Because in reality, all submits are monitored, we just mask off when we choose to act on them.

(Q) Perhaps this shouldn't be called "for", but rather "sources" or "monitor"

autoCenter only applies when there is an overlay. Without an overlay (blockUI=@none) the monitor component will show wherever it is in the page. When there is an overlay, and autoCenter=true, then it will position centered on the overlay. So the default should be true, since that's the most likely desired action.

Beyond Nils' todo list, there are also these items. http://jira.icesoft.org/browse/ICE-7740?focusedCommentId=41172&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_41172

• Preload images so they're ready to display when it's their turn

• Rename caution to session expired
                     text = cfg.sessionExpiredLabel;
                     img = cfg.cautionImgUrl;
  monitor/connect_caution.gif

• Event masking. default is act on all events, but allow specifying events we're only interested in

Suggest using @disabled instead of @none for JSF consistency?

Yes, let's do that.

"Should the monitor continue to show idle during the unmonitored submit? "Yes.

The idea is that the app. can add a "global" monitor for all general submits and other component or region specific monitors with custom messages, or UIblocking, etc. 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.

Nothing wrong with "for" unless we're using it in a way that will be counter-intuitive to experienced JSF developers.

Yes

Agreed. @none is how f:ajax execute and render does it, but @disabled is more clear that the UI blocking is turned off.

Fixed javascript building
Altered label and image use to facilitate facets feature later. General refactor and renaming
Overlay opacity issue where monitor is translucent as well, which required making the clone monitor a sibling not child, which required solving centring and cleanup issues
Handle showing the overlay and not auto centering, which doesn't clone, but has to make original monitor element show through the overlay
Initial wiring up of network/server/session error callbacks. But the core error dialog instead comes up while we're showing active.

(Q) Seems like we need to leave the overlay showing when errors. Core error dialog has button to reload, but we have nothing if not using facet. Should we have a reload button when no facet?

(Q) When showing the overlay and not auto centring, the monitor element is behind the overlay, and so is a bit dimmed, and is of course non-interactive. Should I instead do something else?

TODO: Rename all CSS styleClasses from if-sub-mon* to ice-sub-mon*

scratchpad
Subversion 30233

Removed an odd class import from SubmitMonitorMeta that caused build failure on non-Mac platforms. Probably the IDE automatically mis-added the import when the meta class was first being made.

scratchpad
Subversion 30256

Resummarisation of api / features:

blockUI = @all / @none / @source / panelId. Default is @all
@all : document.body
@source : Core gives us a source element that initiated the submit.
Not sure if component root element or inner element.
h:commandLink specifies form as source.
@none : no overlay
id : An id of an element to do the overlay on

for = space delimited list of search strings, that gets translated to clientId(s) / element id(s).
If the source element is in or equal to any of these, then we take action.
Default when unspecified is all submitting components
Apps may have global monitor for all general submits and region specific monitors with custom labels/facets
Will need to manage global and regional monitor interactions, especially with multiple possible overlays. Precedencing?

autoCenter = Only applies when using an overlay, specifies whether to centre on the overlay or remain in place. Default is true.
Without an overlay, the monitor already remains in place
When showing the overlay and autoCenter=false, if the monitor is behind the overlay, it's dimmed and non-interactive.

facets: idle, active, serverError, networkError, sessionExpired
If there is a facet, it takes precedence over the label, image.
Like core error handling, when not facet, add a reload button

Converted the blockUI property from a Boolean to a String, using the @all, @source, @none, for-style-search-string syntax.

I noticed that with the showcase dataTable example, when using @source (which becomes the dataTable), or the form id or the dataTable id, the monitor is vertically centered but left aligned over the dataTable or form. When using @all, it is horizontally centered. It might be due to some app specific funky styling, so it would be good to test in a simpler app to ensure that the @source and id settings for blockUI do result in horizontal centering.

scratchpad
Subversion 30268

I've started some initial testing on this component and the first failure has appeared. ace:submitMonitor will not enter a busy state for submits made via f:ajax. You can reproduce this issue with my test app located here: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Manual/submitMonitor. This is scratchpad revision# 30256.

Added support for facets: idle, active, serverError, networkError, sessionExpired. If there is a facet, it takes precedence over the label and image. Now the label and image are rendered from the server, so the javascript won't have to care or know if a facet is being used or not.

scratchpad
Subversion 30305

Changed all the monitor references to submitmonitor, to follow our ACE naming practices. It took several commits to do, since I used repository moves to preserve commit histories.

Also, fixed two css issues that I noticed. Some of the rules needed to be updated due to adding an extra div, I believe in Subversion 30233. And the combined.css @ResourceDependency was missing from SubmitMonitorMeta.

scratchpad
Subversion 30307, 30308, 30309, 30310, 30311

To facilitate backporting this to EE 3.0, removed dependence on BridgeSetup. Because of this, I had to rework some styling and positioning over the overlay, and while I was doing that I fixed the @source/id centering as well as improved @all centering to stay fixed in the center of the viewport regardless of scrolling.

scratchpad
Subversion 30317

With ICEfaces EE 3.0, our bridge still hooks into the jsf.js hooks for when JSF initiates the request, so our ice.onBeforeSubmit, ice.onBeforeUpdate, ice.onAfterUpdate, ice.onNetworkError, ice.onServerError, ice.onSessionExpiry callbacks are invoked in that scenario.

This means that ace:submitMonitor works with f:ajax + h: components in ICEfaces EE 3.0. I will investigate replicating this capability with ICEfaces 3.2.

On the EE 3.0 branch, after using the overlay, it was not properly restoring the event listeners, so subsequent f:ajax calls were not succeeding in submitting. The dataTable paging submits were working, so it was specific to the element restoration code. The isNumeric() work-around wasn't sufficient, and needed further development.

patch branch
Subversion 30338

Attached test case that reproduces an issue found with singleSubmit and and inputText field.

Steps:

• Load welcomeICEfaces.jsf
• Enter in some text into the Input #1: text field.
• Click on the "Goto Page 1" commandButton.
• The submitMonitor message is shown but does not navigate to the next page.
• If you enter in some text, focus away from the input field, there by letting the value change happen, and then click on the button, correct navigation occurs.

Customer has also requested that the modal background later be darker or less transparent.

Make overlay darker and more noticeable.

@source mode had problems with adding iframe and div to leaf elements, like a text input. Instead add to @source's parent. Also, if part of the source element was scrolled out of view, the overlay was not covering it properly.

@all had problem with covering the whole area when the body has margins or is scrollable.

scratchpad
Subversion 30366

patch branch
Subversion 30367

http://localhost:8080/submitMonitor/submitMonitorFAjaxBttn.jsf

QA's testing of submitMonitor found an issue where after several submits by an h:commandButton with f:ajax, the submitMonitor would leave the overlay up and show the idle message. Investigation showed that on subsequent clicks the submitMonitor's callbacks with the bridge were being called progressively more times per request, with the multiple redundant state transitions breaking the overlay and event blocking restoration. This was because the whole form was being updated, including the submitMonitor itself, so its javascript was being re-run, which caused a new instance of the SubmitMonitor javascript object to be registered with the bridge callbacks, without the old instance being cleaned up. In fact, there is no API for removing defunct callbacks from the bridge, so it's necessary to register a single set of them once, that can then find the submitMonitor. The redesign for this should likely be done in conjunction with the development of the for property, which is when multiple submitMonitor components, concurrently existing in the view, will become supported.

So, for now, the issue of the whole form being updated was pursued. This was due to ICE-8214, so it's fix was ported onto the patch branch, and shown to resolve the issue.

patch branch
Subversion 30374

With the onblur then onclick issue, the general idea I will be prototyping is to handle the onblur as usual, and then save a reference to the source element as well as the timestamp of the beginning of the request. The reference will be nulled on request completion. In the eventSink, which is the code that is executed in place of the regular event handling, the onclick handling will retain access to the original onclick function, and if it's the first onclick, and is from a different element, and is within a very short timeframe of the onblur submit, then the original function will be called. That will then do a submit, which will make the bridge request callbacks be called. The callbacks will be made to notice that they're being called for an element that's not the original, so they'll do nothing.

It was originally thought that since the previous comment's issue, of the multiple callback calls, was somewhat similar, that looking into it would be beneficial for solving this, but they're just different enough, as the other issue involves one request with multiple callback calls for the same element, whereas this issue is for multiple requests, each for a different element.

Fixed the double submit issue where there is an h: input component that uses icecore:singleSubmit or f:ajax, or an ice: input component that uses partialSubmit=true, and the user enters something into the input component and then directly clicks on something like a commandButton, and we expect first the onblur/onchange/onfocusout from the input component to do a submit, then we expect the commandButton to do a submit. The submitMonitor previously stopped the commandButton submit from happening, and now it allows it to happen. Double/triple clicking on the commandButton will result in it submitting only once, not two or three times. Note that there is now a small delay in the overlay and popup showing, to allow that click to register in the browser.

To accomplish this, I had to:

Add onclick event sink that sees: (1) if click is first click after the original submit started, (2) if the event triggering element or capturing element is different than the originally submitting element, then we anticipate and condone a possible onclick handler somewhere might do a submit. If there was an onclick handler on the element then it's called, otherwise it continues bubbling up. With blockUI=@source/id the event could bubble up past the overlay to an icecore:singleSubmit. If (1) or (2) fail, then we pass the event to our event sink.

On it's own, this wasn't sufficient, because a click requires a mouse down and then mouse up on the same thing, which wasn't happening, as the mouse going down was triggering the inputText submit, which showed the overlay and popup, which thwarted the mouse up on the now covered commandButton. So I had to introduce a delay to the appearance of the overlay and popup.

Unfortunately, that introduced a flicker between the two submits of the overlay and popup being hidden and re-shown with this delay in-between. I had to add a state machine that tracked the "anticipated" submit from the click (no guarantee there would be a second submit), and made the idle processing be delayed on a timeout, so that the possible new active handling could happen first, and if so, then we skipped the transition to the intermediate idle state. That is, except for @source and @none modes, since @none doesn't use an overlay, and @source shows the overlay on different elements, so we needed to follow the typical pattern of show on A->hide->show on B->hide, for it.

I found a deficiency in the onclick event sink (2) checking of if the event triggering element or capturing element is different than the originally submitting element. For a complex component, the event related elements are deep within the component, and the originally submitting element is generally the component root element. Likely we'll need to see if the event elements are, or are inside of the originally submitting element, to be sure the click is on another component / element. Especially with ACE synthetic events, that depict themselves as coming from the root of the component, but really come from a real event on a real element deep within. This has been added to my todo list for submitMonitor.

patch branch
Subversion 30393

The use of console.log for submitMonitor javascript logging caused errors in IE, so we the calls were all commented out.

patch branch
Subversion 30397

The double submit issue looks to be resolved. I am seeing two JavaScript errors when running in IE9 Compat mode with the same test case thats attached.

If I click between the two input fields using the mouse I get the following error:

Error: Unable to get value of the property 'srcElement': object is null or undefined

If I tab between the two input fields using the keyboard I get the following error:

Error: Unable to get value of the property 'type': object is null or undefined

Another new issue that has been reported and I can reproduce with my test case is after tabbing out of the input fields the keyboard is no longer responsive. This is so far reproducible in Firefox and IE9 (regular mode) and Chrome.

Steps:

• Focus into the Input #1 and enter some text, tab out into the next field.
• Enter in some text into Input #2 and tab out.
• Focus gets set on the button but tabbing out of this button has no affect.
• Clicking in the input fields works but you can't type anything in or tab out.
• A full browser refresh solves this and it doesn't happen anymore. Seems to only happen on the first access/usage of the page.

The issue with the first time page access is because of the jsessionid removal causing a full form update, which caused the submitMonitor to be updated while it's in the middle of working. This is a known issue, and I've already worked with Cruz for making a test for solving this. In the meanwhile, we've employed the work-around of putting the ace:submitMonitor outside of the form, just inside the body, to minimise the full form updates' abilities to disrupt the submitMonitor. Resolving why there even are full form updates is a multi-faceted set of issues. We've already back-ported ICE-8214 to solve one instance. This one was due to issues related to ICE-8388 - that is, the underlying jsessionid problem behind it, not the caching problem.

Fixed the IE9 compat mode javascript errors.

patch branch
Subversion 30441

Testing found IE7, IE8 issues:

IE 9 Compat view with IE 9 document standards mode: works correctly
IE 9 Compat view with IE 8 document standards mode: popup is centered, and overlay is there to block interactions, but does not show as grey
IE 9 Compat view with IE 7 document standards mode: popup is centered, and overlay is not grey, nor positioned properly so doesn't block other button clicks

Fixed IE 8 issue where overlay was not appearing as transparent grey.

patch branch
Subversion 30502

Fixed IE 7 issue, and even got the overlay working in quirks mode (although the popup is not horizontally centered). Changed from using an iframe to using a div. The iframe would really only help with certain IE 6 scenarios anyway.

patch branch
Subversion 30523

Attached test case that reproduces new issues with the latest code. Load welcomeICEfaces.jsf to see these issues.

Issue #1: ice:inputText valueChangeListener not called in IE8/IE9 Compat mode. On Tab One there is two input fields, enter in some text into input #1 and tab out, valueChangeListener is not called. This is working in Firefox/IE9/Chrome. If I use an h:inputText instead of the ice:inputText I no longer see this issue.

Issue #2: ice:selectOneRadio button selection issue in Chrome/Safari. On Tab Two there is a selectOneRadio button, Once a selection is made the first radio button can't be selected.

Issue #: ice:selectBooleanCheckbox selection issue in Chrome/Safari. One Tab Three there are three checkboxes. None of the these checkboxes can be selected.

Committed a first iteration at the for feature, which uses components specified by the for property to give a list of root elements that will be listened to for submit begin and end events. And submit whose target or srcElement is recursively within the for roots will be responded to, otherwise ignored. It's not supported for multiple submitMonitors can not use overlays that overlap regions in the dom. So no nesting of for regions.

patch branch
Subversion 30624

• Rename all CSS styleClasses from if-sub-mon* to ice-sub-mon*

• resolveFor method now used to resolve findComponent search strings to clientIds, when using for property

• In QA test app, can't change blockUI values, since that updates the submitMonitor element / javascript, which the component doesn't support. Changed the test app to use window scope bean, so can change values and then refresh the page, and have a coherent DOM while not losing the bean state.

• In onAfterUpdate callback, source element parameter is from before submit, and doesn't necessarily exist in DOM in onAfterUpdate, nor would an updated analog necessarily exist in the new DOM either, so can't use that or its id as input to for property check. Changed onAfterUpdate to use flag set onBeforeUpdate by specific monitor. Now QA test app dataTable page changing works.

• Dual form dual submit leaves elements unrolled back. This is because single form dual submit intentionally makes the first submit do the overlay and trap the events, and the second submit restore everything. But with this test, dual form means two different submitMonitors are doing the setup and restore, and that state was per submitMonitor. Now it's global, and works.

patch branch
Subversion 30664

Arran, it's my understanding that ice: components are not intended to be affected by icecore:singleSubmit. You'll still need to set partialSubmit=true on them. Now, they are supposed to ignore icecore:singleSubmit, but if you find that it breaks them, then that is an issue to look into. And these are not issues with ace:submitMonitor.

Attaching updated test case that shows the issue in IE where the valueChangeListener is not being called. This is an issue with the h:inputText as well as the ice:inputText. I also put an h:inputText outside of the panelTabSet as to try and elimate that component as a cause of the issue.

The issue with Crome are still there with the latest code changes.

First off, I changed icecore:singleSubmit handling to work off of bubbled events not captured events, which we've changed on maintenance branch and trunk. I had thought that would fix things, but it still didn't.

From ICE-6178, when it mentions the compat radio and checkbox components with icecore:singleSubmit, this is what it says:

drink(radio button): can be selected only once by arrow key, after that the focus goes back to entire page
language (checkbox): selections can be made by key board, but output is displayed for the last selected item only(known issue)

So there might be some keyboard issues. But that doesn't explain the mouse clicking problems. Looking at issue #3 ice:selectBooleanCheckbox, we see that the problem happens when both the icecore:singleSubmit and the ace:submitMonitor are present. Basically, ice:selectBooleanCheckbox with partialSubmit=true is intended to submit from the onclick, which works with submitMonitor and without icecore:singleSubmit.

What happens without ace:submitMonitor present:

• With icecore:singleSubmit present, icecore:singleSubmit traps the onchange event, and submits.

• With Firefox, the onclick is called before the onchange, and the ice:selectBooleanCheckbox will submit itself if partialSubmit=true. Next, the onchange will cause a submit, if icecore:singleSubmit is present. If both partialSubmit=true and icecore:singleSubmit are present, then two submits will happen.

• With Chrome, the onchange happens first, and will cause a submit if icecore:singleSubmit is present. If partialSubmit=true, then the subsequent onclick will cause a submit as well. If both partialSubmit=true and icecore:singleSubmit are present, then two submits will happen.

What happens with ace:submitMonitor present:

• When the first submit happens, ace:submitMonitor traps the subsequent events on ice:selectBooleanCheckbox, but not the icecore:singleSubmit event handling, which uses a different way of listening for events, that ace:submitMonitor doesn't modify. And probably could not, as it is.

• With Firefox, if partialSubmit=true, then onclick causes a submit, and later if icecore:singleSubmit it present, the onchange is causes it to submit.

• With Chrome, if icecore:singleSubmit is present, the onchange causes a submit, and then the ace:submitMonitor traps all events on the ice:selectBooleanCheckbox, so the onclick is trapped, and the default trap code returns false, which tells the browser to not [un]check the checkbox.

So, in the first trapped click scenario, where we handle sual submits, the codepath for the same element being clicked, will trap the event just the same, but return true instead of false. So no further second submit will happen, but the checkbox state will not be reverted.

For issue #1, in Firefox it works because icecore:singleSubmit will do a submit onchange, which is what comes first. In IE 8, it's an onfocusout, which the code specifically does not do a submit from, because the submitOnBlur flag is by default set to not do submits of text fields from onblur and onfocusout. You'd have to set the flag to false. On IE9, it uses the same event listening mechanism as Firefox, so it responds to the onchange first as well, and so does a submit.

It doesn't matter if submitMonitor is present or not, in the IE6-8 code path, it doesn't listen in on the onchange, just the onfocusout, and that's tied to the submitOnBlur property. I've tested it, and setting it true makes the ice:inputText's valueChangeListener fire, when running under IE8.

For issue #2 with the ice:selectOneRadio, I can reproduce it before my code change for #3, and can not reproduce it after the code change.

Also, it looks like there's an app bug, since each of the radios has the same value of 300, and not the 100,200,300 that seems intended.

Committed change to event trap code, that handles the first click, to return true when the click is on the same element as caused the submit. It won't call any onclick handler though. This is necessary for input type=checkbox, where a return of false would revert the checking action. It also appears to help with radio buttons.

patch branch
Subversion 30682

Committed the change to the icecore:singleSubmit processing, to bring it in line with trunk, for using bubbled events instead of capture phase events.

patch branch
Subversion 30683

When there is no text label, for a given state, then don't even render the text span, and only render the element for the image, which reduces the empty space to the right of the image.

Change image rendering so that instead of rendering img tags with hard-coded src urls, we instead render span tags that use background image styling, so that applications can override the styling to use their own images. This was problematic, since IE before 9 doesn't support the CSS3 background-size property, so there isn't a way to automatically style the image span to be the right size for the image. Setting the padding was working, but the image span was taking the height of the text span, so the padding was specific to both the image height and the text font height. Art guided me to set "display: inline-block" on the image span, to exclude the text height, so that the padding would only be dependent on the image height. So if the application changes the image, they'll need to also change the padding, which isn't so bad.

One thing that was on my todo list was to make blockUI=id behave like blockUI=@all with dual submits in that the overlay should remain up and not flicker between showing the first submit and the second submit. But with my testing, it looks like previous changes have already accomplished this. Likely, when changing the dual submit handling to work with different submitMonitors.

The code was doing event handler restoration and overlay teardown in onAfterUpdate, which was not good because if elements were updated that render event handlers, then those would get stomped with the old handlers, which could be using stale closure context. Better to restore the event handlers in onBeforeUpdate. I was going to restore the event hadlers then and do the overlay teardown in onAfterUpdate, in case the update itself took a noticeable amount of time, which would add noticeable complexity to the submitMonitor javascript, but then I noticed that the compat notification component just did everything in onBeforeUpdate. So I just made the trivial fix, and didn't delve into the more complex fix. If that becomes necessary in the future, then we can cross that bridge then.

patch branch
Subversion 30807

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.

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.

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

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

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.