Using overflow:auto on tbody causes its cells to be different widths than thead's cells widths




Layout: Tables
15 years ago
9 years ago


(Reporter: Keld R. Hansen, Unassigned)



Windows 2000

Firefox Tracking Flags

(Not tracked)




(2 attachments, 1 obsolete attachment)



15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

The Table Layout in the test case will sometimes (most times) render
incorrectly, leading to table cells missing or in wrong places (shifted a couple
of columns to the right), or cell heights suddenly being twice or thrice as tall
as needed.

Reproducible: Always

Steps to Reproduce:
1. View the test case
2. Scroll down in the scrollable table until you see a layout problem
3. Reload page and try again if you don't see any problem

Actual Results:  
Table Layout was incorrect (see GIF image at for example)

Expected Results:  
Rendered the cells in their proper place instead of shifting them to the right

Problem was in 1.4 as well, but I wanted to wait until 1.5 was relased in case
the bug was fixed.

Comment 1

15 years ago
Created attachment 133752 [details]
Example of faulty rendering

Comment 2

15 years ago
Complete test case for offline viewing can be downloaded at
WFM on WinXP trunk 2003102004.

Reporter: please download a recent nightly build from
<> and try again.
If it works, please resolve this bug as WFM. Thanks !

Comment 4

15 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031021

There is a strange thing going on here, 
Opera 7.20 has only a scrollbar to the right, scrolling the whole document.
Mozilla has this too, baut also a second scrollbar just at the border of the table.

Clicking on the Validator link, something gets validated as valid HTML 4.01
transitional, but not this file here.

Calling validator manually with this URL inserted, I had to override the
doctype, to reduce the errors from 1281 to 1.

From the source:
<!DOCTYPE HTML><html><head>
  <meta CONTENT="Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
Gecko/20031007" NAME="UserAgent">

That seems to be hardcoded, as I´m using BuildID 2003102104,
and at a rough glance Opera 7.20 is showing the same code.

I made a local copy of the page, and there was no difference to the website,
seen with opera and Mozilla.
I replaced <Doctype HTML> with <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "">
Still same difference:
Opera shows one scrollbar for the document, Mozilla shows additionally a
horizontal and a vertical scrollbar for the table.
Maybe that is because my screen resolution is 800x600, and they recommend
1024x768, but Opera is fine with 800x600.
I didn´t see the black area shown in the attachment, but as I´m not on
broadband, I didn´t clear the cache.


Comment 5

15 years ago
The nightly build is much, much better, but there's still a couple of issues:

1) There is suddenly a horizontal scroll bar. How do I eliminate this (CSS?).
Mozilla should not span the last column in under the scroll bar as it currently
does - the heading should span all the way, but the cells below it should be
limited to not include the scroll bar. Or perhaps the scroll bar should be
entirely outside the columns (ie. the heading should also be limited to the area
up to, but excluding, the scroll bar).

2) Sometimes, the rows are taller than they need to be. See screen shots at and 

3) As you can see from Problem1, the misalignment of columns also still happens
- but very rarely.
Good! Have you tried using a new profile ? Go to Tools->Switch Profile... and
make a new one. Then quit all Mozilla windows and restart it using that profile.

Comment 7

15 years ago
The problem is the same - see

As you can see, the "Log On to vote" text has disappeared from episode 154
(probably pushed out beyond the scroll bar), and the row is unnecessary tall.

However, it is still much, much better than v1.5 was.
The black area shown in <> appears in my
build as well now. I can not, however, track it down with DOM Inspector.

I don't see any CSS or HTML that should produce this black area.
Ever confirmed: true
Keywords: qawanted
Reporter: this seems to WFM now on build 2003102804. Could you try again ? thanks.

Comment 10

14 years ago
The first test case now appears to work properly, but I have another one that

I have changed the source in one place from the one saved by Mozilla - I have
changed BORDER=0 to BORDER=1 for the table to illustrate where Mozilla
mis-aligns the table body cells with the table header cells...

This is with Mozilla 1.6 build 2003102804.

Comment 11

14 years ago
Created attachment 152490 [details]
simplified test case for the table header & body misalignment

Attched a simplified test case for the second URL provided by the Reporter. The
page shows the misaligned table header with other cells.

Looks like number of characters in the html page matters for this problem to
occur. Even if I reduce any unnecessary characters from the page, problem

Comment 12

14 years ago
Created attachment 161308 [details]
more reduced testcase
Attachment #152490 - Attachment is obsolete: true


14 years ago
Keywords: qawanted → testcase
Summary: Improper Table Layout when using TBODY and overflow:auto → Using overflow:auto on tbody causes its cells to be different widths than thead's cells widths

Comment 13

12 years ago
*** Bug 319167 has been marked as a duplicate of this bug. ***

Comment 14

10 years ago
(In reply to comment #12)
> Created an attachment (id=161308) [details]
> more reduced testcase

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/  
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 developers' point of view, this may break the layout of some apps which rely on the traditional behaviour.

The standard <> 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 a feature?

Comment 15

9 years ago
the testcase is wfm
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.