From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (X11; I; Linux 2.2.16 i586) BuildID: 2000071008 The url (a simplified test case) renderes with the 1-px whitespace between table rows only happening every TWO rows. Change the text size (View->Enlarge/Reduce Text size) and apparently randomly it correct it. Reproducible: Always Steps to Reproduce: 1.Open URL. 2.Note 1-px whitespace occurs between every TWO text rows 3.Use View->Enlarge/Reduce Text size several times. It now renders properly under some sizes. Actual Results: At different font sizes, the table renders correctly, otherwise table row spacing occurs every TWO rows. Expected Results: Table rows should easy have 1-px whitespace around them. Additional attachment on way by fellow tester...

Confirming this, I'm seeing this linux build ID 2000071008. On Windows 95, build ID 2000071008 things render fine. I'm guessing that changing the font size is just a means to get different heights for the rows and isn't directly related. I'll attach three testcases: 1) simplified version (1 column, 11 rows) with cellspacing="1" 2) simplified version (1 column, 11 rows) with cellspacing="2" 3) simplified version (4 columns, 11 rows) with cellspacing="2"

Adding testcase keyword. The third testcase I attached as a test for gaps between columns. As far as I can tell, they don't change.

linux, build ID 2000071008 Windows 95, build ID 2000071008 I now have another testcase which I think shows the problem better: http://users.bart.nl/~disttsc/bugzilla/bug45055.html These are 6 tables of 5 rows each with a red transparant background image in the cells and a border-spacing of 0, the only difference between them being the table's height, as indicated above it. The second and the third table have one gap and two gaps respectively while the fourth and the fifth have two rows and one rows overlapping. Here's a similar testcase, but then with a background color in the cells: http://users.bart.nl/~disttsc/bugzilla/bug45055c.html It shows the same gaps, and I assume it has the same overlap. My guess is that though the rows need to have different heights to reach a correct total height (e.g. 21+22+21+22+21=107), the contents of the cells is assumed to be the same height for all when drawing their background.

*** Bug 43859 has been marked as a duplicate of this bug. ***

*** Bug 48174 has been marked as a duplicate of this bug. ***

*** Bug 49383 has been marked as a duplicate of this bug. ***

Related to bug 30036.

Can be seen (2000092720/Win95) on : http://www.bestmat.be/en/descr.html http://www.bestmat.be/en/case_01.html http://www.bestmat.be/en/occas.html Though all table spacing-padding-border are set to 0px, extraneous 1px white rows may appear or disappear when changing view/text size percentages.

extra 1px rows disappeared. seems to be solved.

extra 1px rows disappeared. seems to be solved.

I looked at the testcase on jag's site, and still see the behaviour he described I looked at the case_01.html URL as well, and changing the font size creates one white horizontal line in the table. Verified on debug trunk, oct 17. Axel

Oops ! Right, sorry. I was testing on NS6pr3, without view/font resize, isn't it clever :-) There is an improvement, though : 100% (original size) apparently looks nice everywhere on Bestmat site now.

I've changed the URL to the site's homepage, which exhibits the problem in the top-left navigation menu, the text.html file the URL was pointing to has been purged. The site code will soon be changing to be more 'mozilla-friendly', however the menu problem remains regardless. Confirming bug still present in build 2000112108 Linux. Adding self to cc.

Confirmed on Win95 2000112120 (and any previous build). See bottom of page : http://www.bestmat.be/en/descr.html

Martin: the url http://www.bestmat.be/en/descr.html doesn't have any visible problems, certainly none that I can see which may be the same as the bug reported here. Can you clarify exactly what's wrong there? It's a pretty visible bug, just not n that page :-(. BTW: If I set cellpadding="0" cellspacing="0" in a table, then use border-bottom: 1px solid white; for the rows (works with -top too), then I get pretty much the same problem: one white line drawn every two rows. I don't know if that is of any relevance, but it sure makes it tough to work around in html/css :(. Any possibility of getting a progress update on this? Please? :).

Hi James, On my 2000112120, Win95, variable-width fonts set to 16px by default, one can see this extra white line (1px row) at the bottom-left, with View/Text Size 50%, 90%, 100%, 150% but not (as required) when set to 75%, 120% nor 200% Tell me I'm the only one and I'll be happy ;-)

Martin: what's this white line surrounded by? Text? The yellow bar on the left? Considering it's a mainly white page you saying you're seeing additional whiteness doesn't make it easy to track down :).

Visible 1px white line is 213px wide, 75px from bottom, 0px from left, in the left orange column. Please read page source.

URL from dup that this also occurs on: http://www.rx7forum.com/.

*** Bug 60230 has been marked as a duplicate of this bug. ***

Nominating for nsbeta1 per advice from asa/doron. Isn't this a basic standards-compliance issue?

*** Bug 64500 has been marked as a duplicate of this bug. ***

*** Bug 60579 has been marked as a duplicate of this bug. ***

*** Bug 65831 has been marked as a duplicate of this bug. ***

Version: 0.7 Windows 2000 I think http://www.shieldcardamerica.com/ is another example.

Testcase of Duplicate bug: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22929

*** Bug 65888 has been marked as a duplicate of this bug. ***

*** Bug 67627 has been marked as a duplicate of this bug. ***

Keywords: mostfreq, mozilla0.9.1, mozilla1.0 to get it on all the relevant radars. This is a basic html compliance problem which hasn't been been examined at code level yet. Is this even confirmed as an HTMLTables problem? Whatever the correct component, the problem is still occuring. If this *isn't* an HTMLTables problem, we need to move it quickly. I am growing a little concerned that this bug is being somewhat ignored as a low priority compared to others. Karnaze: could you please take at least an initial look to see if we have the right component? Some sort of movement is needed here, it hasn't been looked at since creation and that was some seven months ago. Thanks.

*** Bug 71287 has been marked as a duplicate of this bug. ***

Moving to mozilla0.9. I'm seeing the problem on Windows on http://users.bart.nl/~disttsc/bugzilla/bug45055.html.

*** Bug 70891 has been marked as a duplicate of this bug. ***

*** Bug 64619 has been marked as a duplicate of this bug. ***

Changing Platform and OS to reflect the conditions of bug 64619, which was deemed a dup of this.

*** Bug 51286 has been marked as a duplicate of this bug. ***

Karnaze: is this ready for review? CC attinasi, waterson, who I'm told are right for this anyway. Be nice to get onto the trunk by end of week *hint*.

QA contact update

Ack. Too bad the blocks don't do this... sr=attinasi

'r' Bernd. I tried the patch it looks great, no more matched lines on tinderbox!!! The only think is, the function arguments in the header file nsTableFrame.h should be the same as in nsTableFrame.cpp @@ -633,7 +634,7 @@ nsIFrame* aRowGroupFrame, nscoord aSumOfRowHeights, nscoord aExcess, - nscoord& aExcessForRowGroup, + nscoord& aExcessForRowGroup, ???? nscoord& aRowGroupYPos);

Aaaargh, Chris my 'r' assumes that your patch passes silently the table regression tests especially it should not assert in http://lxr.mozilla.org/seamonkey/source/layout/html/tests/table/bugs/bug1055-2.h tml

The patches are checked in.

one thing: the testcase from url: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22929 displays the correct cellspacing but not the correct table width. every table should have the same width. the reason why i mention this behavior is i believe this was caused by the last checkin'.

I could see every row has same table width when table width is descripted by pixel size, not percent. I think this problem might be caused by some round-off error (or computing order of width of entire table and each cell.)

Verified that the test case attached has correct cellspacing and table width.. Verified on Build ID # 2001-07-27-00-0.9.2 Marking verified