The stopBlockingUI callback defined to run on onAfterUpdate is never executed.

The pre-request callback to setup the stopBlockingUI callback runs correctly though.

The submitEventBroadcaster function returns a method to broadcast listeners for particular events; it is never called for the 'success' event, though the 'begin' and 'complete' events are both processed.

Can you provide the required steps to go through to reproduce this issue?

Use blockUIOnSubmit via web.xml config param or icecore:config.

When causing an ajax request using any component (checking checkbox, paginating datatable, etc.) the translucent block UI plane is displayed, and the update is visibly applied to the page, but the block UI plane is never hidden.

Very easy to reproduce.

I'd note that Ken changed the error text to read 'consistently'. I observed that all ajax requests were similarly bugged.

This issue is triggered when the received updates wipe out the form used for the postback. During 'success' submit event, which is triggered after the updates are applied, the lookup for the form fails thus canceling the execution of the 'onAfterUpdate' callbacks. This causes the failure because blockUI feature relies on the onAfterUpdate functionality.

Modified filterICEfacesEvents to use only the call stack lookup method to determine if the submit is triggered by ICEfaces bridge. Adapted the lookup mechanism to work with Myfaces as well. Also the XHR object is now consistently used as thread context variable, in Myfaces or Mojarra.

With this change, the blockUIOnSubmit blocker no longer activates at all when singleSubmit is used.

To reproduce, use the showcase sample, the ace:dialog Effects demo, select different dialog sizes or effects using the h:selectOneMenu components. The blocker is not invoked. However, it was previous to this commit.

Added detection for recursive calls into detectCaller() function to avoid infinite loops while inspecting the call stack.

We have regression failures with MyFaces and Webkit browsers related to these changes:

Deryk says:

I was testing showcase-portlets running on MyFaces yesterday and seeing some client-side errors. I then tested the non-portlet version of showcase and saw the same issues.

The relevant points are:

• The errors appear to be constrained to the client during Ajax submissions. For example, when submitting a date with dateTimeEntry example, I got the following in the client console: http://dl.dropbox.com/u/14124/Screenshots/myfaces-datetime-console.png. Note that it does a submit that causes an error which eventually leads to a full reload of the page in this component.
• The problems look to be only occurring on WebKit (Safari, Chrome) browsers. Firefox either doesn't show the same issues or they are handled differently.
• It appears that most components are affected in some way. As noted above, the dateTimeEntry shows the problem when the submit button is pressed. With the checkBoxButton, it appears to do an Ajax request during initial page load (which seems wrong to me): http://dl.dropbox.com/u/14124/Screenshots/myfaces-checkBoxButton-console.png.

Ken has noted that the changes for http://jira.icesoft.org/browse/ICE-8372 look to be the root of the issue. Revision 30015 works and 30016 shows the problems.

So in one of the edits to application.js, there is this code specific to MyFaces where it looks like it tries to go up the call stack to find the XMLHttpRequest parameter:

function filterICEfacesEvents(f) {
return function(e) {
var isICEfacesEvent = false;
var xmlHttpRequestParameter
//lookup the XMLHttpRequest parameter of the calling function to use it as a thread context variable,
//avoiding thus to use global variables
if (window.myfaces) {
//lookup the stack: filterICEfacesEvents < broadCastFunc < arrForEach < each < broadcastEvent < sendEvent [argument 0]
var xmlHttpRequestParameter = arguments.callee.caller.arguments.callee.caller.arguments.callee.caller.arguments.callee.caller.arguments.callee.caller.arguments[0] ;
...

From debugging, it looks like the assumption about the size of the call stack is off. I can only resolve this far down:

arguments.callee.caller.arguments.callee.caller

At that point, then next "arguments" in the chain is null which leads to an error. In Firefox, this doesn't appear to happen but in Chrome, when trying to resolve the chain, it states that the arguments to the forEach() function is "native code" so it returns null.

arguments.callee.caller.arguments.callee.caller
-> function forEach()

arguments.callee.caller.arguments.callee.caller.arguments
-> null

Another regression that started as of 30016 is:

All browsers: ICE-3871 (Fail manually, the outputConnectionStatus does not change its label to 'Disconnected', as expected by the test; in IE only the label changed to 'Caution').

This issue is still present as of svn rvn# 30076.

Removed filterICEFacesEvents() function. Instead of filtering events the page scoped submit callbacks are wired (along with the request scoped submit callbacks) to be invoked every time fullSubmit, singleSubmit or requestUpdate functions are invoked.

This approach, in effect, simulates the behavior we used to have when filtering events but with the advantage of much simpler and faster code.

Re-opening as instructed by Ken.
The following ace:progressBar ajax tests fail due to JS errors occurring in all browsers.
Test application is located here: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/progressBar
Test page: http://localhost:8080/progressBar/progressBarAjax.jsf

1) 'cancel' Event Test (render=@all): JS error when clicking on Cancel button:
In IE8:
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Timestamp: Fri, 20 Jul 2012 17:15:52 UTC

Message: Exception thrown and not caught
Line: 1
Char: 16627
Code: 0
URI: http://localhost:8080/progressBar/javax.faces.resource/bridge.js.jsf?v=28218271

2) 'change' Event Test (render=@all) : same JS error when progressBar reaches the end.

In Firefox and Chrome, for both tests the error in console is: Error: uncaught exception: cannot find enclosing form.

It looks like an ajax update is occurring for the element that is the source of the event. In the past we have resolved this with the following strategy:

+++ src/main/javascript/application.js (working copy)
@@ -108,6 +108,15 @@
}

function formOf(element) {
+ try

catch (e)

+ }
+
+ function formOfNode(element)

This fixes the test case. In the past, DOM operations in the middle of ajax updates have been found to be highly browser-dependent.

In the case of ICEmobile, the javax.faces.ViewState is missing from a failed button click, likely indicating that the ViewState was not "fixed" on the previous update, possibly due to a listener not being called.

Fix for the double back button is being made in ICEmobile: MOBI-271.

Carmen confirms that the specific tests that failed Thursday night (as per her comment "Carmen Cristurean added a comment - 20/Jul/12 01:15 PM" above), now pass with this patch in place. Complete regression tests will run Friday night, we'll have results on Monday morning.

Registered again as ICE-9129. I suppose many people has got problems with ice:panelPopup. After closing of this popup gui stops respond in some test cases.