When running ICE-8959 test case it can be noticed how none of submitMonitor's elements registered with onElementUpdate are updated. This explains why the corresponding callbacks are not invoked.

I modified icefaces3/samples/showcase/showcase/src/main/webapp/resources/examples/ace/tab/tabset.xhtml to have an ace:dateTimeEntry inside the ace:dataTable that's inside a server-side ace:tabSet's ace:tabPane. Switching tabs should cause both the ace:dataTable's onElementUpdate and all the ace:dataTimeEntry components' onElementUpdate functions to call.

Added logging into application.js, and turned on the tabSet logging, to show the calls to the onElementUpdate functions, and this is what it showed:

[window] persisted focus for element "form:tbl:4:__1e_o_input"
=============
ace:tabSet - ID: form:sampleTabSet - submit SS - 113ms
ace:tabSet - ID: form:sampleTabSet - tabChange - 118ms
updated element id: form:sampleTabSet_safe_1
onElementUpdate element id: form:tbl:0:__1e_o
onElementUpdate element id: form:tbl:1:__1e_o
onElementUpdate element id: form:tbl:2:__1e_o
onElementUpdate element id: form:tbl:3:__1e_o
onElementUpdate element id: form:tbl:4:__1e_o
onElementUpdate element id: form:tbl
updated element id: form:sampleTabSet_safe_1_nxt
updated element id: form:sampleTabSet_script
ace:tabSet - ID: form:sampleTabSet - updateProperties DR - 4ms
ace:tabSet - ID: form:sampleTabSet - updateProperties - 11ms

form:tbl corresponds to the ace:dataTable, and __1e_o to the ace:dateTimeEntry. All are getting called.

I've added logging to icefaces3/core/src/main/javascript/application.js which shows what's registered for onElementUpdate and what's getting called.

If you load up the showcase sample application and go to the submitMonitor example, and then change "What to block" to "Whole page", then what should happen is that the submitMonitor_script update should cause the submitMonitor_script callback to occur and clean it up. What actually happens is that the submitMonitor_display update comes first, and since it isn't submitMonitor_script nor an ancestor, then that clears away the callback function for submitMonitor_script.

It looks like any unrelated non-ancestor update can wipe out an onElementUpdate callback function for another update, if it gets processed earlier in the sequence.

Here's the logging of the issue, when changing "What to block" to "Whole page":

onElementUpdate registration element id: submitMonitor_script ancestors: *submitMonitor_script*submitMonitor*submitMonitorGroup*demoPanel_content*demoPanel*completeExample__1e_6*examplePanel_content*examplePanel*primary*mid*container*javax.faces.ViewBody*javax.faces.ViewRoot*

(That shows that onElementUpdate is being registers for submitMonitor_script)

...

updated element id: submitMonitor_display

elementUpdateListeners updated: false idCallbackTuple.ancestors: *submitMonitor_script*submitMonitor*submitMonitorGroup*demoPanel_content*demoPanel*completeExample__1e_6*examplePanel_content*examplePanel*primary*mid*container*javax.faces.ViewBody*javax.faces.ViewRoot*

updated element id: submitMonitor_script

updated element id: dynamic-code-compat

(This shows that the handling of the submitMonitor_display update is clearing out the submitMonitor_script callback, before the submitMonitor_script update handling would have called it.

This time I was able to reproduce the issue. The issue occurs when multiple elements have corresponding onElementUpdate callbacks registered and the incoming updates will modify more than one of these elements.

The applied fix makes sure that the callbacks corresponding to elements that are not updated are not removed from the list of onElementUpdate callbacks.