I've investigated this extensively, but there's still no solution on the horizon.

What I've noticed so far is that when clicking the edit save or edit cancel buttons, the client-side click events are always fired, and the code follows the expected path: edit save handlers in datatable.js, ice.ace.AjaxRequest in core.js, and even the fullSubmit() function in the bridge, but when handling the request to JSF (jsf.ajax.request), the request never reaches the server. The request appears as 'Pending' in the browser console and never gets a response. Trying to trigger subsequent requests (any kind of request, anywhere in the form) after this happens doesn't send a new request to the server, even though the click event is still fired and the code follows the same path; when reaching jsf.ajax.request no new request is sent.

I also tried sending a request with an ace:pushButton inside an expanded row, but it runs into a very similar problem: no request is sent, and it seems like not even the click event listeners are triggered. I thought this issue could be due to the the fact that the data table renders client ids of expanded rows (and of components inside these rows) separated with period characters ('.') to indicate the row level, so I tried and changed the use of this character for the dash ('-'). After this, the issue with the row editor controls was exactly the same, but the issue with ace:pushButton was fixed: a new request was sent every time the button was clicked, and the request was completed successfully.

So, client ids, containing periods might be part of the problem, especially for certain components, but it's still not clear why the initial row editor request inside an expanded row is never completed.

The same behaviour applies with or without ace:ajax.

I also noticed that the first time an expanded row enters in edit mode, all the individual cell editors are updated twice (i.e. there are two 'update' xml elements in the response for each cell editor.

When using MyFaces, there's no issue sending the request and receiving a response. Subsequent requests, anywhere on the page, can still be done after pressing the edit-save and edit-cancel buttons. However, edits made to expanded rows are not applied when trying to save them.

Also, standard h: components are completely unaffected by this.

Assigned to Mircea to analyze why Mojarra doesn't process ace comps the same way that the h: comps are handled.

The request is 'Pending' because the server side goes into an infinite loop when data table tries to iterate over the sub-rows. In DataTable.iterate(FacesContext context, PhaseId phaseId, boolean self) method there is a while loop that has multiple exit points. Debugging shows that line #2394 is reached over and over again when trying to save a sub-row edit.

Later thread dumps show:

"http-nio-8080-exec-5" #49 daemon prio=5 os_prio=31 tid=0x00007f89240d7000 nid=0x8b03 runnable [0x00000001ebe24000]
   java.lang.Thread.State: RUNNABLE
	at java.util.AbstractCollection.toArray(AbstractCollection.java:139)
	at java.util.ArrayList.<init>(ArrayList.java:177)
	at javax.faces.component.UIComponentBase$FacetsMap.keySetIterator(UIComponentBase.java:3034)
	at javax.faces.component.UIComponentBase$FacetsMapValuesIterator.<init>(UIComponentBase.java:3385)
	at javax.faces.component.UIComponentBase$FacetsMapValues.iterator(UIComponentBase.java:3369)
	at javax.faces.component.UIData.restoreDescendantState(UIData.java:2302)
	at javax.faces.component.UIData.restoreDescendantState(UIData.java:2296)
	at javax.faces.component.UIData.restoreDescendantState(UIData.java:2242)
	at javax.faces.component.UIData.setRowIndexWithoutRowStatePreserved(UIData.java:511)
	at javax.faces.component.UIData.setRowIndex(UIData.java:473)
	at org.icefaces.ace.component.datatable.DataTable.setRowIndex(DataTable.java:499)
	at org.icefaces.ace.component.datatable.DataTable.iterate(DataTable.java:2319)
	at org.icefaces.ace.component.datatable.DataTable.iterate(DataTable.java:2197)
	at org.icefaces.ace.component.datatable.DataTable.processDecodes(DataTable.java:460)
	at com.sun.faces.context.PartialViewContextImpl$PhaseAwareVisitCallback.visit(PartialViewContextImpl.java:573)
	at com.sun.faces.component.visit.PartialVisitContext.invokeVisitCallback(PartialVisitContext.java:183)
	at org.icefaces.ace.component.datatable.DataTable.visitTree(DataTable.java:1623)
....

or

"http-nio-8080-exec-5" #49 daemon prio=5 os_prio=31 tid=0x00007f89240d7000 nid=0x8b03 runnable [0x00000001ebe24000]
   java.lang.Thread.State: RUNNABLE
	at javax.faces.component.UIData.saveDescendantState(UIData.java:2385)
	at javax.faces.component.UIData.saveDescendantState(UIData.java:2320)
	at javax.faces.component.UIData.setRowIndexWithoutRowStatePreserved(UIData.java:479)
	at javax.faces.component.UIData.setRowIndex(UIData.java:473)
	at org.icefaces.ace.component.datatable.DataTable.setRowIndex(DataTable.java:499)
	at org.icefaces.ace.component.celleditor.CellEditor.processDecodes(CellEditor.java:77)
	at org.icefaces.ace.component.datatable.DataTable.iterate(DataTable.java:2378)
	at org.icefaces.ace.component.datatable.DataTable.iterate(DataTable.java:2197)
	at org.icefaces.ace.component.datatable.DataTable.processDecodes(DataTable.java:460)
	at com.sun.faces.context.PartialViewContextImpl$PhaseAwareVisitCallback.visit(PartialViewContextImpl.java:573)
	at com.sun.faces.component.visit.PartialVisitContext.invokeVisitCallback(PartialVisitContext.java:183)
	at org.icefaces.ace.component.datatable.DataTable.visitTree(DataTable.java:1623)
....

depending at what time you make the thread dump.

Running with Myfaces the infinite loop is not triggered but the sub-row changes are not saved.

r48613: modified the fix for ICE-10507 to support child rows and to avoid having to alter the table's row index to obtain the editSubmit parameter

Testing notes: please create a test case with multiple levels of child rows, all with cell editors as well, and verify that cell editing works at every row level.

r48614: added missing conditional
r48615: committed fix to the 3.3 EE maintenance branch

Verified ICEfaces 4 trunk r48616. Tomcat 8, IE edge, 11, 10, 9, 8, FF 43, Chrome 49. Ran all related regressions and tested manually using the /views/configPanelTest.jsf which has multiple editable child rows.

There is an issue on the EE-3.3.0 maintenance branch. You can edit all child rows, you can collapse all child rows, but when you expand the rows again, the last child row does not expand out to display.
This can be demonstrated with the QA dataTable /views/configPanelTest.jsf
1.) Load the test app ( /views/configPanelTest.jsf) using ee-3.3.0 maintenance branch dataTable
2.) Expand the last row in the table twice to reveal the sub-rows.
3.) Edit a cell in the last row. Click save.
4.) In the next row up edit a cell and click save.
5.) In the next cell up (parent row) edit a cell and click save.
6.) Starting from the bottom collapse the child rows, then finally the parent row.
7.) Expand the parent row, the first child row will display.
8.) Expand the first child row. the second child row no longer will display.

Closing JIRA again. The issue in the comment above is not related to this fix. It already existed. It can be reproduced with the EE 3.3 P02 release. The EE 3.3 P01 release doesn't show the issue. It can be reproduced even without editing any row, just expanding to the deepest level and then contracting all the way up and then attempting to expand again. Please create a new JIRA for this specific issue.

Resolved. http://jira.icesoft.org/browse/ICE-11001 was opened for the non-relevant issue.