ICEfaces
  1. ICEfaces
  2. ICE-10793

ace:dataTable - cannot edit sub-rows on Row Expansion Test page

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-4.0.0.GA, EE-3.3.0.GA_P03, 4.1.1
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEfaces4 trunk/ EE-3.3.0-maintenance branch r 45915
      Browsers: all
      Server: Tomcat7
    • Assignee Priority:
      P2

      Description

      QA ace:dataTable test application > Row Expansion test:
      - the edit function does not work on the sub-rows from the expanded rows; clicking the icon to submit changes does not update the content of the cell on the page.
      - when trying to edit the sub-row from the last row, the sub-row remains in editing mode that cannot be closed. After this, the rows can no longer be expanded.

      Test app:
      http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dataTable
      Test page: /views/rowExpansionTest.jsf

        Activity

        Hide
        Arturo Zambrano added a comment -

        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.

        Show
        Arturo Zambrano added a comment - 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.
        Hide
        Arturo Zambrano added a comment -

        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.

        Show
        Arturo Zambrano added a comment - 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.
        Hide
        Ken Fyten added a comment -

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

        Show
        Ken Fyten added a comment - Assigned to Mircea to analyze why Mojarra doesn't process ace comps the same way that the h: comps are handled.
        Hide
        Mircea Toma added a comment - - edited

        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.

        Show
        Mircea Toma added a comment - - edited 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.
        Hide
        Arturo Zambrano added a comment -

        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.

        Show
        Arturo Zambrano added a comment - 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.
        Hide
        Arturo Zambrano added a comment -

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

        Show
        Arturo Zambrano added a comment - r48614: added missing conditional r48615: committed fix to the 3.3 EE maintenance branch
        Hide
        Liana Munroe added a comment - - edited

        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.

        Show
        Liana Munroe added a comment - - edited 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.
        Hide
        Arturo Zambrano added a comment -

        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.

        Show
        Arturo Zambrano added a comment - 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.
        Hide
        Liana Munroe added a comment -

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

        Show
        Liana Munroe added a comment - Resolved. http://jira.icesoft.org/browse/ICE-11001 was opened for the non-relevant issue.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Carmen Cristurean
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: