415412 - table rows stretch to fill scrollable tbody in gecko 1.9/Firefox 3, but should not

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[James Barrante]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9b3pre) Gecko/2008013104 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9b3pre) Gecko/2008013104 Minefield/3.0b3pre

Given a <table> OR a <tbody> with explicit height specifications, Gecko 1.9 will stretch table rows to fill up the specified height. This is a break with the behavior of previous Gecko versions, where the rows would not stretch.

Reproducible: Always




This testcase with a defined table height illustrates another bug which could
be related:
Compare the renderings of (Gecko/2008010605 Minefield/3.0b3pre) and
(Gecko/20071127 Firefox/2.0.0.11).  
The difference is the height of the cells: 
  Firefox 2 renders in the way everyone's used to and the way it should be
(Opera 9.25 does the same).
  Firefox 3 stretches the height of the cells, as do MSIE6 and MSIE7.

Now from a web developer's point of view, this may break the layout of some
apps which rely on the traditional behaviour.

The standard <http://www.w3.org/TR/CSS21/tables.html#height-layout> says:

  "The height of a 'table-row' element's box is calculated once the user agent
has all the cells in the row available: it is the maximum of the row's
specified 'height' and the minimum height (MIN) required by the cells."

Even with height specifications, say style="height:1em" applied to both TRs and
TDs, Firefox 3 stretches the rows' height.  IMHO: Without a CSS switch for the
TABLE element in the form of "-moz-table-row-height-algo" the behaviour
observed in Firefox 3 is unacceptable.

To the developers: Is this a bug or one major architecture change not mentioned by the release notes?

Comment 1

[James Barrante]

Attachment: testcase

Comment 2

[James Barrante]

(In reply to comment #1)
> This testcase with a defined table height illustrates another bug which 
> could be related:

I just copied my original comment from 
<https://bugzilla.mozilla.org/show_bug.cgi?id=223077> 
which did not get any attention.

Comment 3

[Elmar Ludwig]

CSS2.1 section 17.5.3 states that:

The height of a table is given by the 'height' property for the 'table' or 'inline-table' element. A value of 'auto' means that the height is the sum of the row heights plus any cell spacing or borders. Any other value is treated as a minimum height. CSS 2.1 does not define how extra space is distributed when the 'height' property causes the table to be taller than it otherwise would be.

So, reading this and the discussion in bug 139201, I think the row height is simply undefined in this case. This might even be a duplicate of bug 139201.

Comment 4

[James Barrante]

Thanks for confirming what I thought and -- my fault -- not pointing out specifically: simply undefined. So the question must be rephrased: Why introduce a different behavior (compared to the one practiced before)? Therefore, leaving this bug as UNRESOLVED and not marked as dupe -- considering the 1.9 branch -- would be kindly appreciated.

Comment 5

[Plucera]

I can confirm this bug/regression with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4. 

This new way of rendering break our web applications. I have created a workaround which set the extra space to the last row but it still has issues (using background-colors on rows for instance).

TBODY :last-child { height: auto; vertical-align: top; }

I prefer the old behavior as the new one may be achieved by setting height to auto for the table rows.

Comment 6

[Henrik Bentel]

I'm also bitten by this bug. 
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

Have a table with a dynamic number of rows, 0 to many. 

tbody has an explicit height with "overflow-y: auto" for scrollbar on the body.

No matter what I try, I'm unable to get the table to render consistently for both Firefox 2 and 3. 

Comment 7

[Bernd]

> Why introduce a different behavior (compared to the one practiced before)?

Because the old one is a bug?

The space below the cell in the old behavior did not match the cell spacing spec.


CSS 2.1 does not define how extra space is distributed when
the 'height' property causes the table to be taller than it otherwise would be.

>Firefox 3 stretches the height of the cells, as do MSIE6 and MSIE7.

Cross browser compatibility seems like a reasonable choice to me if the spec doesn't define this.

Comment 8

[Plucera]

> Cross browser compatibility seems like a reasonable choice to me if the spec
> doesn't define this.

The problem is that there is a work-around that we use in IE to get the FF2 behaviour. With the new approach in FF3 there is no satisfying work-around other then adding an extra empty row in each table.

Comment 9

[Plucera]

I'm very sad to see that this regression/different behaviour isn't fixed in the 3.0 release! 

The cross browser point is a bit out of its context as Opera and Safari (maybe more) uses FF2 way of rendering.

This forces us to not upgrade to FF3 nor recommend our customers the upgrade.

Comment 10

[Matthew Knowlton]

Attachment: Another testcase example

This uses the same CSS used in an application for my company that is now breaking. it has a set height of 300px; the max-height property wouldn't properly apply, so I had to use height, in Firefox 2 the 3 rows only take up as much space as they need. In Firefox 3 however, the rows span to the entire height of the tbody, any attempt I make to set a height on tr or td does not make any difference.

Comment 11

[Cédric Chantepie]

I also think old behaviour was better. If it wasn't contrary to some CSS specs, I think FF3 should go back.

Comment 12

[Matthew Knowlton]

(In reply to comment #7)
> > Why introduce a different behavior (compared to the one practiced before)?
> 
> Because the old one is a bug?
> 
> The space below the cell in the old behavior did not match the cell spacing
> spec.
> 
> 
> CSS 2.1 does not define how extra space is distributed when
> the 'height' property causes the table to be taller than it otherwise would be.
> 
> >Firefox 3 stretches the height of the cells, as do MSIE6 and MSIE7.
> 
> Cross browser compatibility seems like a reasonable choice to me if the spec
> doesn't define this.
> 

I understand where you are coming from about browser compatability, however at the moment it is impossible to define certain CSS properties to the selectors for table elements with a display set as table-row, some of which don't apply to table-cell or table-header either. Namely the height, min-height, and max-height properties. I have also noticed the visibility property doesn't always properly apply to these element's selectors either.

Comment 13

[Cédric Chantepie]

(In reply to comment #5)
> I can confirm this bug/regression with Mozilla/5.0 (Windows; U; Windows NT 5.1;
> en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4. 
> 
> This new way of rendering break our web applications. I have created a
> workaround which set the extra space to the last row but it still has issues
> (using background-colors on rows for instance).
> 
> TBODY :last-child { height: auto; vertical-align: top; }
> 
> I prefer the old behavior as the new one may be achieved by setting height to
> auto for the table rows.
> 

An unsatisfying workaround could be : 

tbody :last-child { height: 100%; }

it keep other rows with minimum height but always display overflow scroll is
set as auto on tbody or table

Comment 14

[Matthew Knowlton]

Attachment: Testcase2

My other testcase wasn't rendering fully for some reason, this one should work.

Comment 15

[Cédric Chantepie]

"The height of a table is given by the 'height' property for the 'table' or
'inline-table' element. A value of 'auto' means that the height is the sum of
the row heights plus any cell spacing or borders. Any other value is treated as
a minimum height. >>CSS 2.1 does not define how extra space is distributed when
the 'height' property causes the table to be taller than it otherwise would
be<<. Note. Future updates of CSS may specify this further."
[http://www.w3.org/TR/CSS21/tables.html#height-layout]

Old behaviour doesn't seem to break CSS2.1 compliance, but FF3 behaviour change
break compat' with its previous versions and with other browsers like Safari
and Opera.

Comment 16

[Matthew Knowlton]

Another unsatisfying workaround which is the one I tried before you suggested
yours was:


tbody *:last-child > *
{
 padding-bottom:100%;
 vertical-align:baseline;                               
}

Comment 17

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Attachment: Minimal Testcase: only a table with height=200px

It seems to me a correct behaviour. If the extra width is distributed along columns, why extra width must not be distribute along rows?

Anyway Fx should offer a way to set how one element must distribute its extra space. What about a -moz property?

(In reply to comment #8)
> The problem is that there is a work-around that we use in IE to get the FF2
> behaviour.

What is this workaround?

Comment 18

[Cédric Chantepie]

Issue is not whether it is correct or not, as CSS specs doesn't specify how to distribute extra space (see comments before).
Issue is that Firefox change its behaviour about such situation, without obvious reason (no compliance cause), what could be called a regression.

Comment 19

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

(In reply to comment #18)
> Issue is not whether it is correct or not, as CSS specs doesn't specify how to
> distribute extra space (see comments before).

I didn't say it's more compliant with W3C specs. I said I don't find a good reason to have a behaviour along x and another behaviour along y.

Comment 20

[Plucera]

(In reply to comment #17)
> (In reply to comment #8)
> > The problem is that there is a work-around that we use in IE to get the FF2
> > behaviour.
> 
> What is this workaround? 
> 

I think it's to complex to describe here, but basicaly it involves not setting the table height, auto height for rows and sourounding the table with an overflowing div. It's a no good solution that doesn't apply to FF. Our solution is some what they are using at http://www.imaputz.com/cssStuff/bigFourVersion.html 

I think the main problem is that the new behaviour is totaly ignoring the height specification when there are to few rows to fill the table. With the new behaviour there is no way to define a specific row or cell height that is honored. FF2 has the ability to distribute space as FF3 does by setting the height to auto. The new behaviour therefore is achiveable in FF2 while the old behaviour is imposible to provoke in FF3.

Comment 21

[Plucera]

(In reply to comment #19)
> (In reply to comment #18)
> > Issue is not whether it is correct or not, as CSS specs doesn't specify how to
> > distribute extra space (see comments before).
> 
> I didn't say it's more compliant with W3C specs. I said I don't find a good
> reason to have a behaviour along x and another behaviour along y.
> 

The problem is that x as in columns is often predefined and given specific widths. Y as in rows on the other hand is more likely to vary and can be filled up over time (in db driven applications)

As we has to specify a height for the table to be able to make it scroll (often with the nice feature to hade the headers stay in place, e.g. only scrolling the tbody) we always end up with rows being stretched when there are to few to fill the area. This causes tables to look in different ways depending on the amount of rows.

I hope you see the problem and not only the, why should x as y don't. I realy doesn't see a problem with consistent behaviour as long as height and width are honored.

Comment 22

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Attachment: Minimal Testcase #2: max-height ignored

(In reply to comment #20)
> With the new behaviour there is no way to define a specific row or cell height 
> that is honored.

Mh. This is true. I tried to set a max-height to the row, but it is ignored.
If max-height will work as expected, it will be a simple workaround (max-height=0)

Comment 23

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

(In reply to comment #21)
> As we has to specify a height for the table to be able to make it scroll 
> (often with the nice feature to hade the headers stay in place, e.g. only 
> scrolling the tbody) we always end up with rows being stretched when there 
> are to few to fill the area.

Well, for this there's a simple workaround:

table {
	width: 100%
}

table tbody {
	max-height: 200px;
	overflow-y: auto;
	display: block;
}

See this example:
http://pazziaumana.netsons.org/bug-415412_workaround.html

Comment 24

[Plucera]

(In reply to comment #23)
> Well, for this there's a simple workaround:
> 
> table {
>         width: 100%
> }
> 
> table tbody {
>         max-height: 200px;
>         overflow-y: auto;
>         display: block;
> }
> 
> See this example:
> http://pazziaumana.netsons.org/bug-415412_workaround.html
> 

I was simplyfing my example as we need to define table height. We use this in web based applications filling the whole screen no mather what resolution used. A so we have table height defined with percentage values in order to make it fill up (we also have tfoot elements placed at the bottom of the table that has to be in the same place always). It's in these cases that few rows end up being stretched but when the tables are filled the heights av normal. The workaround therefore is not aplieable in our case.

Comment 25

[Cédric Chantepie]

(In reply to comment #19)
> (In reply to comment #18)
> > Issue is not whether it is correct or not, as CSS specs doesn't specify how to
> > distribute extra space (see comments before).
> 
> I didn't say it's more compliant with W3C specs. I said I don't find a good
> reason to have a behaviour along x and another behaviour along y.

I might have been more coherent indeed to have the same behaviour in x and y, but I prefer Firefox to be more stable than more coherent, when it doesn't hurt specs. 
To my mind, regression is the main issue.

Comment 26

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

(In reply to comment #24)
> I was simplifying my example as we need to define table height. We use this in
> web based applications filling the whole screen no matter what resolution 
> used.

You can do this with JS.

> We have table height defined with percentage values in order to make it
> fill up 

Can you give me an example?

Comment 27

[Jacob Lewellen]

I had a similar issue in which I had a web component that required the column widths to be displayed properly.  Firefox 3 stretched them all to fill the div that the table was inside.  I ended up getting around it by setting the table width to 0 pixels.  This made the table snap to the size of the td's inside (or perhaps the size of the content, which was equivalent in this case).

Maybe that would work in the vertical direction as well.

Comment 28

[Justin]

(In reply to comment #23)
> (In reply to comment #21)
> > As we has to specify a height for the table to be able to make it scroll 
> > (often with the nice feature to hade the headers stay in place, e.g. only 
> > scrolling the tbody) we always end up with rows being stretched when there 
> > are to few to fill the area.
> 
> Well, for this there's a simple workaround:
> 
> table {
>         width: 100%
> }
> 
> table tbody {
>         max-height: 200px;
>         overflow-y: auto;
>         display: block;
> }
> 
> See this example:
> http://pazziaumana.netsons.org/bug-415412_workaround.html
> 

I don't see that as an appropriate solution. DIsplaying a tbody as a block has all sorts of side-effects that counteract the reason behind using a table in the first place, namely the cells in the tbody do not line up with the header cells when using a fixed position header with a scrollable tbody (which is what this bug is about in the first place).

Example: http://sandbox.enjoybeing.net/ff3-fixed-height-tbody-bug.html

Comment 29

[dj]

Bump, short of a fix, has anyone figured out a simple workaround?  I've tried trimming the table to match "normal" row heights when they're being stretched but I haven't (yet) figured out how to make it work cleanly on tables that have yet-another table with scrollable tbody within.  I'm still working on it, but would love to know if a) there's any push to fix this or b) anyone has a fairly clean workaround?

Comment 30

[Terri Layman]

I did the following and it seemed to fix the issue....

At the end of your tbody, enter the following: (so enter this after any dynamically created rows
<tr style= "height: auto"><td colspan="7"></td></tr>

The colspan will be the number of columns you need to span over.

Then in your css, add the following:
TBODY.priceSheet:last-child { height: auto; vertical-align: top; }

the .(name) being your table's class.

That should fix you up!  I tried to find the webpage I found the solution on but had no luck.

I hope this helps you!

-Terri

Comment 31

[dj]

Thank you Terri, I think I understand that solution, and may still use it, but I'm generating these tables via jsf's datatable tag which means the extra row would need to be part of the application data/business logic or I'd need to customize the component.  That's not to say I couldn't do that, but I think I finally got my Javascript working 99% of the time (seems to work in all the cases I've tested so far).  Here's the Javascript I've built (it's split apart for debugging so please no complaints about optimizing):

function fixFF() {
 if (whichBrs() == "Firefox") {
  var tbodies=document.getElementsByTagName('tbody');
  for (var i = 0; i < tbodies.length; i++) {
   var tbody = tbodies[i];
   if (tbody) {
    var trows = tbody.rows;
    var rowCount = trows.length;
    var rowHeight = trows[0].clientHeight;
    var rowsHeight = rowCount * rowHeight;
    var tbodyHeight = tbody.clientHeight;
    if (rowsHeight >= tbodyHeight) {
     var tbodyStyle = tbody.style;
     if (typeof tbodyStyle != "undefined") {
      var tbodyStyleHeight = tbody.style.height;
      if (typeof tbodyStyleHeight != "undefined") {
       if (rowsHeight > tbodyHeight) {
        tbody.style.height = tbodyHeight + "px";
       }
       else {
        tbody.style.height = "auto";
       }
      }
     }
    }
   }
  }
 }
}

Besides optimizing (faster tag search, not running against ALL tbodys, etc.), it also needs to check the firefox version which it doesn't do yet.  The weird assign/check undefined code was added because of what seems to be a bug in Firebug on FF 3 when stepping through code and I'll probably pull it too.

I call it on load and any time a table's data is updated via AJAXed code and so far so good (crosses fingers).

Comment 32

[Kevin]

I tried the suggested fixes listed above, and as of now, they only 'almost' work...specifically, my TRs resize properly, but now, if the vertical scroll is active, my headers within the <thead></thead> tag are being included in the scrollable content (instead of maintaining the intended position outside the scrolling content.)

Any suggestions on how to keep header behavior AND avoid the expanding TR bug?

Comment 33

[dj]

(In reply to comment #32)
> I tried the suggested fixes listed above, and as of now, they only 'almost'
> work...specifically, my TRs resize properly, but now, if the vertical scroll is
> active, my headers within the <thead></thead> tag are being included in the
> scrollable content (instead of maintaining the intended position outside the
> scrolling content.)
> 
> Any suggestions on how to keep header behavior AND avoid the expanding TR bug?

I'm not seeing the same behavior, but I know the placement of the tdiv is important.

Here's the current state of that same fixFF() function, in case it helps.  Note, it makes certain assumptions about line height, etc. that should probably be better calculated but it works in my situation well enough.  Some of the extra undefined checks are because of random issues, probably related to firebug (guessing), where the var doesn't fully exist.  Hope it helps:

function fixFF() {
 if (UserAgent.brand() == "Firefox" && UserAgent.version() == "3") {
  var tbodies=document.getElementsByTagName('tbody');
  for (var i = 0; i < tbodies.length; i++) {
   var tbody = tbodies[i];
   if (tbody) {
    var trows = tbody.rows;
    var rowCount = trows.length;
    var firstRow = trows[0];
    if (firstRow) {
     var rowHeight = firstRow.clientHeight;
     var rowsHeight = rowCount * rowHeight;
     var tbodyHeight = tbody.clientHeight;
     if (rowsHeight >= tbodyHeight) {
      var tbodyStyle = tbody.style;
      if (typeof tbodyStyle != "undefined") {
       var tbodyStyleHeight = tbody.style.height;
       if (typeof tbodyStyleHeight != "undefined") {
        if (rowsHeight > tbodyHeight) {
         if (rowCount * 20 > tbodyHeight) {
          tbody.style.height = tbodyHeight + "px";
         }
         else {
          tbody.style.height = "auto";
         }
        }
        else {
         tbody.style.height = "auto";
        }
       }
      }
     }
     else { 
      if (rowHeight > 20) {
       tbody.style.height = rowCount * 20 + "px";
      }
     }
    }
   }
  }
 }
}

Comment 34

[Mike Ness]

For several months I've been using a modified version of dj's javascript (thanks dj!), which has worked well for me. My version doesn't look at all tbody's, just those with the class 'scrollContent' (which sets the height and overflow). It's below. It loops through the rows, accumulating the row heights. Once the height of the rows is larger than the tbody.clientHeight it breaks out, because scrolling IS needed. If the total row height is less than the tbody.clientHeight, it resets tbody height to "auto".

function fixFF3() {
	// Fix Firefox 3 bug where scrolling table rows fill tbody height if there are not enough rows to scroll.
	if (navigator.userAgent.indexOf("Firefox/3") > -1) {
		var tbodies = document.getElementsByClassName('scrollContent');
		for (var i = 0; i < tbodies.length; i++) {
			var tbody = tbodies[i];
			if (tbody) {
				var trows = tbody.rows;
				var tbodyHeight = tbody.clientHeight;
				var rowsHeight = 0;
				for (var r = 0; r < trows.length; r++) {
					rowsHeight += trows[r].clientHeight;
					if (rowsHeight >= tbodyHeight) {
						break;
					}
				}
				if (rowsHeight <= (tbodyHeight+1)) {
					// Scrolling not needed, reset the tbody height to auto.
					tbody.style.height = "auto";
				}
			}
		}
	}
}

with:

<body onload="fixFF3();">

Comment 35

[Kevin]

Thanks for your responses guys, I appreciate the help.  Unfortunately, I couldn't get the JS fix to work as desired, I think because of some heavy requirements for fixed content elsewhere on the page (I'm not wild about fixed content by and large, but it's a requirement...)
Anyway, I doubled back and tried the CSS fixes, which gave me the same <thead> issues, but inserted a little script to count up how many rows the table had (coming in from the DB), and only apply the fix if it was less than enough to force the scroll...works like a charm.

I wish someone would take up this issue, but in the meantime, thanks again for all the help.


(In reply to comment #34)
> For several months I've been using a modified version of dj's javascript
> (thanks dj!), which has worked well for me. My version doesn't look at all
> tbody's, just those with the class 'scrollContent' (which sets the height and
> overflow). It's below. It loops through the rows, accumulating the row heights.
> Once the height of the rows is larger than the tbody.clientHeight it breaks
> out, because scrolling IS needed. If the total row height is less than the
> tbody.clientHeight, it resets tbody height to "auto".
> 
> function fixFF3() {
>     // Fix Firefox 3 bug where scrolling table rows fill tbody height if there
> are not enough rows to scroll.
>     if (navigator.userAgent.indexOf("Firefox/3") > -1) {
>         var tbodies = document.getElementsByClassName('scrollContent');
>         for (var i = 0; i < tbodies.length; i++) {
>             var tbody = tbodies[i];
>             if (tbody) {
>                 var trows = tbody.rows;
>                 var tbodyHeight = tbody.clientHeight;
>                 var rowsHeight = 0;
>                 for (var r = 0; r < trows.length; r++) {
>                     rowsHeight += trows[r].clientHeight;
>                     if (rowsHeight >= tbodyHeight) {
>                         break;
>                     }
>                 }
>                 if (rowsHeight <= (tbodyHeight+1)) {
>                     // Scrolling not needed, reset the tbody height to auto.
>                     tbody.style.height = "auto";
>                 }
>             }
>         }
>     }
> }
> 
> with:
> 
> <body onload="fixFF3();">

Comment 36

[PR]

Throwing my hat in the "gawd this is killing me" camp (and mixing metaphors at the same time).

We have an internal web application, and this issue alone has prevented a firm-wide upgrade to ffx3.    Regarding the debate over "what should it do given that it's not spec'd fully".  My feeling is simply: In ffx3 we can no longer vertically scroll a TBODY with a variable/unknown number of rows while maintaining a reasonable layout.  This represents a loss of functionality from ffx2.  Removing functionality without the spec telling us we need to do so doesn't sit well...

The various workarounds (while certainly helpful - thanks all) all have pretty serious negative side effects (a 100% height final row gives you scrolling always, a blank row at the bottom messes up front-end sorting etc.)

Anyway - hat thrown in ring.

Comment 37

[NC]

To deal with the last row filling the void but giving extra scroll issue, I've found this way to deal with it:

.list tbody tr {
	
	height:10%;
	
}

.trlast { /* last row */
	position:relative;
	z-index:-1;
	display:table;
}			

tbody {		
		
	height: 100%;
	overflow-y: auto;
	overflow-x: hidden;		
}

For the sorting problem, I still have no clue. Anybody?

Comment 38

[Tim Lowrimore]

For the sorting problem, you'll need to separate your model from your view (if you've not already done that), and either sort the model, or proxy your model with a sorter, and sort an array of model indices.  Once sorted, notify the view (i.e. the table) and re-render.  

This is a considerable amount of work for sure, but it will get you what you need, and it's much more flexible.

Cheers,
Tim

Comment 39

[Tim Lowrimore]

Oh, and because you'd no longer be sorting your view, you can always ensure the "work-around" row is the last row in your view.

Cheers,
Tim

Comment 40

[NC]

Thanks Tim,
I'm using the jquery TableSorter 2.0, so I'm having some problems to work it around.

Cheers,
NC


(In reply to comment #39)
> Oh, and because you'd no longer be sorting your view, you can always ensure the
> "work-around" row is the last row in your view.
> 
> Cheers,
> Tim

Comment 41

[Nathaniel Engelsen]

More work-around javascript. This time with jQuery (off of Mike's Function):

function fixFF3grids(griddiv) {
    // Fix Firefox 3 bug where scrolling table rows fill tbody height if there 
    // are not enough rows to scroll.
    if (navigator.userAgent.indexOf("Firefox/3") > -1) {
        var tbodies = $(griddiv + " tbody");
        tbodies.each(function() {
            var trows = $(this).children("tr");
            var tbodyHeight = $(this).height();
            var rowsHeight = 0;
            trows.each(function() {
                rowsHeight += $(this).height();
                if (rowsHeight >= tbodyHeight) return false;
            });
            if (rowsHeight <= (tbodyHeight + 1)) $(this).height("auto");
        });
    }
}

Obviously one can pass in the actual table or tbody itself, but I have need to pass in the table container.

(In reply to comment #34)
> For several months I've been using a modified version of dj's javascript
> (thanks dj!), which has worked well for me. My version doesn't look at all
> tbody's, just those with the class 'scrollContent' (which sets the height and
> overflow). It's below. It loops through the rows, accumulating the row heights.
> Once the height of the rows is larger than the tbody.clientHeight it breaks
> out, because scrolling IS needed. If the total row height is less than the
> tbody.clientHeight, it resets tbody height to "auto".
> 
> function fixFF3() {
>     // Fix Firefox 3 bug where scrolling table rows fill tbody height if there
> are not enough rows to scroll.
>     if (navigator.userAgent.indexOf("Firefox/3") > -1) {
>         var tbodies = document.getElementsByClassName('scrollContent');
>         for (var i = 0; i < tbodies.length; i++) {
>             var tbody = tbodies[i];
>             if (tbody) {
>                 var trows = tbody.rows;
>                 var tbodyHeight = tbody.clientHeight;
>                 var rowsHeight = 0;
>                 for (var r = 0; r < trows.length; r++) {
>                     rowsHeight += trows[r].clientHeight;
>                     if (rowsHeight >= tbodyHeight) {
>                         break;
>                     }
>                 }
>                 if (rowsHeight <= (tbodyHeight+1)) {
>                     // Scrolling not needed, reset the tbody height to auto.
>                     tbody.style.height = "auto";
>                 }
>             }
>         }
>     }
> }
> 
> with:
> 
> <body onload="fixFF3();">

Comment 42

[Bernd]

the support for scrollable rowgroups got removed see bug 28800

Comment 43

[dj]

Are you kidding?  This is NOT the same issue as bug 28800, or the resolution to 28800 caused a new bug.