Based on my discussion with the developer regarding this issue, the issue is caused by improper standard implementation in IE 7.

A workaround in IE 7 would be to set the height manually during OnAfterInitialize event based on the WebGrid number of rows. Here is the snippet:

function wgScroll_OnAfterInitialize(controlId)
{
	var wgScroll = ISGetObject(controlId);

	if (IS.ie && IS.GetIEVersion() == 7)
	{
	    var totalRows = parseInt(wgScroll.TotalRows);

	    //70 is the status bar height
	    //24 is the height of a single row content
	    wgScroll.SetHeight((70 + (24 * totalRows)));
	}
	
	return true;
}

Hi Glenn,

This solution doesn't work for grids with paging, once I go to a different page the grid will resize (incorrectly) again and I'm sure that some operations requiring a flypostback (sorting, refreshing) will resize the grid as well.

Try adding to the grid:

<LayoutSettings PagingMode="ClassicPaging" PagingSize="10">
        <ClientSideEvents OnAfterInitialize="wgScroll_OnAfterInitialize" />
    </LayoutSettings>    

 And on the DS:

protected void InitScroll(object sender, ISNet.WebUI.WebGrid.DataSourceEventArgs e)
        {
            e.DataSource = new List<KeyValuePair<string, string>>()
            {
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test"),
                new KeyValuePair<string, string>("Test", "Test")
            };
        }

 Take a look at the grid behaviour on initial load and after paging. Is the ONLY solution giving it a fixed height?

Under such circumstances, you will need to use the OnAfterResponseProcess client side event handler. Based on the action name in the event handler you might need to invoke the resize height again.

Here is the modified snippet:

function GridCustomResize(controlId)
{
    var wgScroll = ISGetObject(controlId);

    if (IS.ie && IS.GetIEVersion() == 7)
    {
        var tableElem = wgScroll.RootTable.GetElement(WG40.BODY, WG40.HTMLTABLE)
        var totalRows = tableElem.getElementsByTagName('tr').length;

        //70 is the status bar height
        //22 is the height of a single row content
        wgScroll.SetHeight((70 + (24 * totalRows)));
    }
}

function wgScroll_OnAfterInitialize(controlId)
{
    GridCustomResize(controlId);
	
	return true;
}

function wgScroll_OnAfterResponseProcess(controlId, actionName, lastRequestObject, xmlResponseObject)
{
	var wgScroll = ISGetObject(controlId);

	switch (actionName)
	{
	    case "Paging":
	        GridCustomResize(controlId);
	        break;
	}
	
	return true;
}

For some reason setHeight onAfterInitialize and setHeight OnAfterResponseProcess behave differently (they don't resize the grid to the same height). My solution for this was way overkill but worked, used jQuery selectors to get the rowcount and the height of the elements inside the grid.

In my test, I set a static height for each row (24px) since all the row is a single line row. If you are using multi row cell or other scenario in which the height for each row could be different, the workaround would be to iterate all the row and sum all the height, as you have done using jQuery.