test app use ...SC14260\home.xhtml

What is being seen is not a blur effect or anything like that. When a scrollable table is loaded, it goes through several positioning calculations to align the headers to the body columns. For a brief moment all body columns lose their original widths and thus they all appear crammed in the viewport width, while each of them gets its specific width that will align it to its corresponding header. This situation is only visible on tables that have a high number of columns and that are much wider than the viewport. The only work around is to temporarily conceal the table body, so that the table appears blank while all these calculations take place. After all columns have their correct widths set, then the table contents are shown again all aligned. This can be accomplished with the following client side code:

1. Add styleClass="conceal-body-contents" to the ace:dataTable component.

2. Add the following <style> element in the header of the page.

<style type="text/css">
.conceal-body-contents .ui-datatable-scrollable-body .ui-widget-content {
visibility: hidden;
}
</style>

3. Add an id to the ace:dataTable component and to its parent h:form, so we can have a predictable client id for the table. In this example, we simply set them to 'table' and 'form', respectively.

4. Add the following <script> element at the end of the page.

<script type="text/javascript">
setTimeout(function(){
	ice.ace.jq(ice.ace.escapeClientId('form:table')).removeClass('conceal-body-contents');
}, 1000);
</script>

5. Don't forget to set the ace:dataTable component to scrollable="true" to actually test this workaround.

So, what this code does is to set the body table to invisible. However, it still takes space, so that our code can do all the alignment calculations correctly. After these calculations are finished, we remove the style class that caused the body table to be invisible, and, thus, the table is finally revealed all aligned correctly.

There's no hook to execute this code right after all the alignment calculations, so we assume they will take no longer than one second, which is a conservative assumption.

I verified that this situation only happens when loading the page and not when resizing the window.

r51184: removed style class used by scrollable body table that contained 'table-layout:fixed;', since it was causing all cells to be crammed into the viewpoert width. Moreover, it's not necessary, since the table itself receives the styling 'table-layout:auto;' in its style attribute when doing the resizeScrolling() calculations

It turns out that having 'table-layout:fixed;' was causing the issue, and it was caused from the moment the HTML was loaded, not when performing the resizeScrolling() calculations. It doesn't seem to be necessary at all, since that styling is overridden by 'table-layout:auto;' on the style attribute of the table.

Re-opened for 4.3.

r52186: committed fix to 4.0 trunk