fails with both 3.3.0-P02 and P03.

Added 4.2 target, since I would reproduce the issue with the 4.x trunk as well.

r48952 fix to restore visibility to child rows that were previously hidden in the client, after a parent row is expanded
r48953: committed fix to the 4.x trunk

The issue was that there was a mismatch in child rows states between the server-side state and the client-side state. After contracting a row, some javascript in the client adds "display:none;" to all its child rows, and after expanding that same row again, this styling was not removed from its child rows. This fix adds a function does just that: it removes "display:none;" from all first-level child rows of a particular row, and it calls itself recursively on child rows that are also expanded.

Verified ICEfaces 4 trunk, ee-3.3.0 maintenance branch r48953. Tomcat 8, IE edge, 11, 10, 9, 8, 7, FF 43, Chrome 50 with test case and regression tests. New test app /ICE-11001.jsf has been checked in.

In the QA test app /rowExpansionTest.jsf the most inner child rows contain a panel. If you expand the row to the inner-most child, then contract the parent, the panel stays visible. This is also seen when testing with EE-3.3.0 p02 and EE-4.0.0 libs.
Is this an issue?

It seems like an issue. I'll take a look.

I examined that last issue, and it's not really an issue. It's just the way things work.

In that test page, the table uses both row expansion and panel expansion, and it's the expansion panel that remains open after contracting the main row. There is only one expansion panel associated with one main row. Because there's only one expansion toggler for both types on expansion, and this table has both types of expansion, then the very last expansion toggler is used for the panel expansion, while all the others are used for row expansion. So, contracting the parent row also contracts all child rows but not the expansion panel. If we also contracted the expansion panel, then we wouldn't be allowing the possibility of only showing the expansion panels (without showing the child rows). There could be a counter argument that maybe the user would intend to close all the child rows and the expansion panel when contracting the main row, but that really would depend on how each table is set up, how many child rows it has, how it's meant to be used, etc. It's better to opt to keep both types of expansion separate and thus allow for more possibilities.