Attached screen shot and test case that shows the issue. Note: the icefaces.jar/icefaces-ace.jar/icefaces-compat.jar need to be added into the war to run.

To see the issue, load welcomeICEfaces.jsf and edit a row.

Committed fix at revision 38626. The code already contemplated resizing the header columns as well, when the body columns change (as a result of activating the row editor, for example), but some bugs were preventing this functionality from working correctly. The main cause was that some of the dynamically generated CSS rules to resize the columns were lingering at the moment when the column widths were being recalculated, so when the row editor was activated, the widths weren't being adjusted.

A minor issue still remains at this moment: there's a slight width mismatch between the header columns and the body columns that are editable (i.e. that have a cell editor component). It doesn't occur when activating the row editor for the first row, but it does occur for all other rows.

Committed fix for misalignment issue with editable columns at revision 38641.

There's only one minor issue in IE10 when the body table is scrollable (vertically) and the root container has a horiztonal scrollbar (e.g. because of specifying a width): when moving the horizontal scrollbar all the way to the right, the body columns don't align with the header columns. The columns realign when moving back to the left. This is caused because IE10 renders the vertical scrollbar inside the element, instead of outside, like other browsers. So, the vertical scrollbar is part of the element and when scrolling horizontally the eidth of the vertical scrollbar will be taken into account and the columns will misalign by about 20px (i.e. the width of the vertical scrollbar). I've tried different things like adjusting paddings and margins of the different nodes that compose the table, and that doesn't seem to have any effect. I've also tried modifying widths, but that breakes the already calculated widths of the columns. At the moment there's not much that can be done about this issue.

With the patched build the customer is reporting am Invalid Arguement JavaScript error in IE9. This looks to be caused by the following code:

if (this.styleSheets) { // remove previous column size rules
for (var i = 0; i < this.styleSheets.length; i++) {
var sheet = this.styleSheets[i];
if (ie8 || ie9)

else

}
while (this.styleSheets.length > 0)

I was able to reproduce this in IE8 and IE9 with the provided test case. I was able to see the issue by double clicking a row (on row selection). After a browser refresh the error no longer happens. To reproduce again I have to clear the browser cache and the cookies.

Additionally they asked if this code would leave some memory footprint?

while (this.styleSheets.length > 0)

Backported fixes (including ICE-9532) to 3.3 EE maintenance branch at revision 38733.

Verified fix using icefaces-ee-3.3.0_P01-Williams-tableConfigEnh-Build rev# 38805 (Firefox 25, IE10, Chrome30), and no issues have been found.