Thank you for taking the time to provide the sample. By following the instruction, I was able to reproduce the infinite recursive loop in SetColumnLabelWidth if WebGrid is invisible.

Per my test, the reported problem doesn't persist when Visible property is set to false.

<ISWebGrid:WebGrid ID="WebGrid2" runat="server" Height="300px" Width="100%"
    UseDefaultStyle="True" DataSourceID="AccessDataSource1" Visible="false">
    ...
</ISWebGrid:WebGrid>

According to the information I got from WebGrid development team, the SetColumnLabelWidth is used to prettify WebGrid column appearance. Preventing this function to work may cause the grid appearing disorderly after set back to visible.

The SetColumnLabelWidth function is called over 2716 times through what appears to be a call from WGUIEngine.RealignSortIndicators(this.RootTable);

Per my test, this behavior doesn't causing the browser to stop responding; or cpu usage increasing; etc. Please feel free to let me know if there is anything that I might miss during my investigation.

Look forward to hearing back from you.

I also saw what the SetColumnLabelWidth function does to help set the auto width, which has its own "wait until the column/grid is visible" logic.

The issue in our scenario is that the outer DIV (higher up in the DOM) is being hidden by an element/control that has no idea what is in the container, so it doesn't know the grid is there.  So it can't call Visible=false or ClientVisible=false.

Can the grid and SetColumnLabelWidth work together to check if any of its parent elements are hidden, and skip the continuous timeout checks per column?  Perhaps a single grid "check if visible" timeout (maybe not so aggresive/quick at 10ms) that can then call into the columns to set their label width, etc?  I know it can't detect when it becomes visible due to a parent element, so this might be at least a consolidated check.

Mike