Closed Bug 10002 Opened 22 years ago Closed 21 years ago

Problem with rowspan skipping rows


(Core :: Layout, defect, P3)

Windows NT





(Reporter: jrblier, Assigned: karnaze)




(Whiteboard: [TESTCASE] &


(2 files)

Mozilla M8 can't display perfectly the page at

This page has been enhanced for Netscape 3, Communicator 4 through 4.6.1, for Internet Explorer 4 and 5.

M5 through M7 were able to render a lot better, though net perfectly.

The only problem I'm seeing (on Linux) is problems with the background images
for the two table cells in the top row being drawn additionally a little below
where they should be (in addition to their correct position).  Probably either
compositor or tables...
Assignee: don → rickg
Component: Browser-General → Layout
Assignee: rickg → karnaze
Chris -- please take a look.
Target Milestone: M10
QA Contact: leger → petersen
As of the July 26 build on Linux, I only see the following problems:
1. The navigation bar on the left has too much space between the images
(reported in another bug).
2. The image rollovers can get "hung". Also in another bug.
3. The banner at the bottom which reads:

Dernière modification (GMT-5): Thu Jul 8 17:54:20 1999.
© 1999 DynEC, inc. | Avis légal | Vie privée

Is not there.

I don't see the background image bug that mentioned at
Whiteboard: [MAKINGTEST]
Attached file testcase
Looking at this page using 1999-08-01-16-M9 on Windows 98.
I see the top and bottom navigation bars and nothing in between, giving
a total page height of about 100 pixels. The cause of this problem seems
to be a row coded as "<TR> </TR>" which makes the whole table disappear.
Have attached a simple testcase for this problem (id=1101).
Summary: BAD HTML rendering on a public web site → Problem with rowspan skipping rows
Whiteboard: [TESTCASE] → [TESTCASE] &
I've simplified the testcase further - attachment coming up.
I've removed the nested table, the colspan, the last column, and the
(BTW, it is only the first row _not_ the whole table that disappears.)
The first row disappears only if cellspacing=0 but the table is rendered
badly with different values as well.
I'm not sure if this is the same bug, but I've added it to the testcase.
Attached file simpler testcase
Closed: 22 years ago
Resolution: --- → WORKSFORME
I'm checking build 1999-08-23-09 on Win98

I've checked both mats' and my testcases, and it works ok now.
(Caused by karnaze fixing other bugs I think.)
The build is currently too unstable to test the original page (bug 12330),
but I go ahead and mark this one WORKSFORME.
With the Aug 24th build, the page renders the same as Comm 4.6. Marking as
verified works for me.
Whiteboard: [TESTCASE] & → more test cases needed [TESTCASE] &
Target Milestone: M10 → M11
Jacques: I am reopening this bug based on your email below. If you could provide
small isolated test cases for each of the bugs you mention, I would greatly
appreciate it.

I did post the original 10002 bug! Thank you all for resolving the display of through the latest build.

95% of the bugs are fixed. The only 5% remaining is strange.

Since I'm not familiar with the bugzilla page and don't want to mess up with
anything, I would would like to know what you think about the last 5%.

1. In Communicator 4.6 the left-hand menu is composed of 5 main gray buttons
that touch one another. In the most recent Mozilla build these 5 main gray
buttons do
not touch, showing about 2 or 3 pixels in between.!

2. In Communicator 4.6 the table row that include the top menu aligned to the
right fits in height the images button included, letting the menu integrate
with the rest of the page. In the most recent Mozilla build this table row
height are about 3 or 4 pixels more in height, with the result that the top menu
does not
integrate well with the rest of the page.

3. It may be related to another bug, or work in progress, but the nightly Moz
takes forever to compose It hangs somewhere before completing
the page. Sometimes composing the same page very quickly!

Anyway, it is a lot better than M8.

All test done on Windows NT sp 5.

Furthermore, this last 5% problem with pixels spacing problems is not a "Major"
layout bug anymore. I think it should be classified as "Normal".
Resolution: WORKSFORME → ---
Thanks Jacques. I've included your email here.

As per your request I posted a testcase on the Negotium Web site. The URL is

I fully think that this is the core of our problem with layout "Moz vs Comm
4.6". This test case should suffice to fix all layout problem with those extra
space pixels.

If need be I'll post a second testcase for the upper-right horizontal menu.
These testcase JavaScript are generated by Macromedia Dreamweaver 2.0.1.
In Navigator 3, Communicator 4 to 4.6 and in Explorer 4 and 5 the buttons are
touching each other. In Moz there are extra invisible space, about 3 pixels.
This is not a critical problem, though.
The new test case looks the same to me in Nav4.6 and Gecko. Is this the right
test case?
Whiteboard: more test cases needed [TESTCASE] & → [TESTCASE] &
Problem 1 & 2 that Jacques mentions are both a duplicate of bug #5821
It causes images that are wrapped in an anchor to have a few pixel spacing
below them.

I saw this problem, but I knew that the remaining problems are a duplicate,
so I marked this one worksforme.
I't my fault that I didn't talk about that.
I was too reading with surprise that petersen said it renders exactly the same
as Comm 4.6 ...

Now I could mark it a duplicate of 5821, but I rather wait for the dust
to settle. :)
Closed: 22 years ago21 years ago
Resolution: --- → WORKSFORME
I haven't tried a build for quite some time.
This bug is now fixed.
Tested with Build ID 1999091518.
Works for me also in the Sept 16th build.
You need to log in before you can comment on or make changes to this bug.